From wleggette@cleversafe.com Wed Jan 20 10:56:52 2010 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 0ECD63A63EB for ; Wed, 20 Jan 2010 10:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Ee29qASNfYCU for ; Wed, 20 Jan 2010 10:56:51 -0800 (PST) Received: from p01c12o142.mxlogic.net (p01c12o142.mxlogic.net [208.65.145.65]) by core3.amsl.com (Postfix) with ESMTP id 149283A69BA for ; Wed, 20 Jan 2010 10:56:47 -0800 (PST) Received: from unknown [216.166.12.69] by p01c12o142.mxlogic.net(mxl_mta-6.4.0-2) with SMTP id be1575b4.0.1374.00-006.2962.p01c12o142.mxlogic.net (envelope-from ); Wed, 20 Jan 2010 11:56:47 -0700 (MST) X-MXL-Hash: 4b5751ef3ffb2f3a-0ee8b33e2013a52c938d85038ce1d4f484f97121 Received: from AUSP01VMBX09.collaborationhost.net ([10.2.8.161]) by AUSP01MHUB03.collaborationhost.net ([10.2.8.78]) with mapi; Wed, 20 Jan 2010 12:55:46 -0600 From: Wesley Leggette To: "decade@ietf.org" Date: Wed, 20 Jan 2010 12:55:40 -0600 Thread-Topic: Related problem statement Thread-Index: AcqaAijiubwjSFr1y02O0rY4K1dGMQ== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010011101)] X-MAIL-FROM: X-SOURCE-IP: [(unknown)] X-AnalysisOut: [v=1.0 c=1 a=TYbMNos9eHUa9bm6/o8foQ==:17 a=uC97h7ikpj0iITe1] X-AnalysisOut: [WbsA:9 a=76my-1_yAJm04gxKMwP8jZR0IVMA:4] Subject: [decade] Related problem statement X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 18:56:52 -0000 Hello, My company has a distributed storage system product which uses Erasure Code= s to store data reliably. We are hoping to standardize our protocols and data formats. I recently sent out a question tot he apps discuss list asking if anybody was working on something similar, and DECADE was pointed out to me. Our problem and requirements are slightly different than those pointed out in your problem statement. Specifically, we are more of a "hosted P2P" environment. In effect, this means that some of the dynamic content lookup is a bit simpler in the initial implementation of our system (because the data is stored on fixed nodes run by one or more hosting providers). We als= o originally envisioned (and have currently implemented) an application layer protocol for data transport, though the possibility of a "transport agnostic" protocol which could be encapsulated in P2P application protocols is intriguing. I think that there could be a lot of overlap between the requirements we ar= e facing and the requirements which will have to be addressed by DECADE. I will be shortly submitting a problem statement of our own. Once I do, I would like to invite you to read it and let me know if there would be any interest in converging our two problems. In the mean time, what is the status of this body? I see from the schedule that you have an initial charter proposal. Has there been much progress since then? Wesley Leggette=20 From melodysong@huawei.com Wed Jan 20 23:27:22 2010 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 73B0C3A69AE for ; Wed, 20 Jan 2010 23:27:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.471 X-Spam-Level: X-Spam-Status: No, score=0.471 tagged_above=-999 required=5 tests=[AWL=-0.668, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_URI_REPLICA=1.634] 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 t4XdhQ5wtlwr for ; Wed, 20 Jan 2010 23:27:21 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 395893A690B for ; Wed, 20 Jan 2010 23:27:21 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWL001F85ZMXP@szxga03-in.huawei.com> for decade@ietf.org; Thu, 21 Jan 2010 15:26:11 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWL002R05ZMI0@szxga03-in.huawei.com> for decade@ietf.org; Thu, 21 Jan 2010 15:26:10 +0800 (CST) Received: from s64081a ([10.164.12.24]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KWL0092P5ZJA5@szxml06-in.huawei.com> for decade@ietf.org; Thu, 21 Jan 2010 15:26:10 +0800 (CST) Date: Thu, 21 Jan 2010 15:26:07 +0800 From: Song Haibin In-reply-to: To: 'Wesley Leggette' , decade@ietf.org Message-id: <00c401ca9a6a$ff7837c0$180ca40a@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: AcqaAijiubwjSFr1y02O0rY4K1dGMQAOe+MA Subject: Re: [decade] Related problem statement X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 07:27:22 -0000 Hi Wesley, After reading some materials from your company's websit. From http://www.cleversafe.com/vision/object-storage http://www.cleversafe.com/vision/Replication_vs._Information_Dispersal http://www.cleversafe.org/dispersed-storage/idas http://www.cleversafe.com/vision/Dispersed_Data_Archiving_Top-10-Features I think the product of your company is using Erasure Codes to store contents and using p2p technologies to organize contents and in-network storage devices. So I believe it is trying to solve some different problems than DECADE's. Because we don't want to design a whole system but only a signaling protocol between p2p application and in-network storage for resource control and indication of underlying data access/transport protocols. I'm happy to read your problem statement draft after you finish it. But I don't know if there is opportunity to converge these two different problem statements. As for the status, we held a bar BOF at IETF 75, and a BOF at IETF 76. We are trying to clarifing the scope and looking forward to form an working group. Thank you, Haibin > -----Original Message----- > From: decade-bounces@ietf.org > [mailto:decade-bounces@ietf.org] On Behalf Of Wesley Leggette > Sent: Thursday, January 21, 2010 2:56 AM > To: decade@ietf.org > Subject: [decade] Related problem statement > > Hello, > > My company has a distributed storage system product which > uses Erasure Codes to store data reliably. We are hoping to > standardize our protocols and data formats. I recently sent > out a question tot he apps discuss list asking if anybody was > working on something similar, and DECADE was pointed out to me. > > Our problem and requirements are slightly different than > those pointed out in your problem statement. Specifically, we > are more of a "hosted P2P" > environment. In effect, this means that some of the dynamic > content lookup is a bit simpler in the initial implementation > of our system (because the data is stored on fixed nodes run > by one or more hosting providers). We also originally > envisioned (and have currently implemented) an application > layer protocol for data transport, though the possibility of > a "transport agnostic" protocol which could be encapsulated > in P2P application protocols is intriguing. > > I think that there could be a lot of overlap between the > requirements we are facing and the requirements which will > have to be addressed by DECADE. > > I will be shortly submitting a problem statement of our own. > Once I do, I would like to invite you to read it and let me > know if there would be any interest in converging our two problems. > > > In the mean time, what is the status of this body? I see from > the schedule that you have an initial charter proposal. Has > there been much progress since then? > > Wesley Leggette > > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > From melodysong@huawei.com Wed Jan 20 23:29:39 2010 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 0C45F3A697A for ; Wed, 20 Jan 2010 23:29:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.029 X-Spam-Level: X-Spam-Status: No, score=-0.029 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_WEOFFER=0.3] 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 LUqhHjx0sKN9 for ; Wed, 20 Jan 2010 23:29:37 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 4E0143A690B for ; Wed, 20 Jan 2010 23:29:37 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWL00AJT64YNJ@szxga01-in.huawei.com> for decade@ietf.org; Thu, 21 Jan 2010 15:29:23 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWL00FPL64Y1F@szxga01-in.huawei.com> for decade@ietf.org; Thu, 21 Jan 2010 15:29:22 +0800 (CST) Received: from s64081a ([10.164.12.24]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KWL00CXY64V4M@szxml04-in.huawei.com> for decade@ietf.org; Thu, 21 Jan 2010 15:29:22 +0800 (CST) Date: Thu, 21 Jan 2010 15:29:19 +0800 From: Song Haibin To: decade@ietf.org Message-id: <00c501ca9a6b$71fa7ce0$180ca40a@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: AcqVbiE7OCPdRj/vRb2EHDqL4aDIkAAJIr0QAAE5OKIAJU1FwAEPj4Yw Subject: [decade] FW: Application protocol for distributed 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: Thu, 21 Jan 2010 07:29:39 -0000 This is an email from the Apps discussion list. I think it is worth to be forwarded to DECADE list. Haibin > -----Original Message----- > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > Sent: Saturday, January 16, 2010 6:20 AM > To: Wesley Leggette; Song Haibin; Alexey Melnikov > Cc: IETF Apps Discuss; Woundy, Richard > Subject: RE: Application protocol for distributed storage > > Wesley, > > >Instead, we are interested in using IDAs[2] > > You didn't supply a reference for IDAs, but I suspect this is what you > meant: . It > seems that you are storing slices of data across distributed > storage locations, (1) to maximize storage efficiency and (2) > to minimize data exposure if one or more storage servers are > compromised. If so, I agree you do seem to be trying to solve > a slightly different problem than Decade's. > > At the same time, there is some potential areas of > commonality, particular in the case of data control and > transport protocols. > > From : "If > your application is housing your metadata, and only object > storage is required, the Simple Object interface can be > accessed with either a Java SDK, or HTTP/REST API. Simple > PUT, GET, DELETE commands allow your applications to access > digital content, and the resulting object ID is stored > directly within the application." > > From > -10-Featur > es>: "dsNet systems can be accessed in numerous ways. Today we offer > iSCSI and a straight block interface, soon to come releases > support FTP, NFS, CIFS (SMB) and webDAV, making your data > universally accessible to any application you might conceive > for it. Our authentication systems are also pluggable > through PAM (Pluggable Authentication Modules)." > > Since your company already sells a product, I am curious > about which interoperability problems you are trying to solve > (or avoid) by posting your internet-drafts. Are you enabling > any third-party client to leverage your cloud storage? Could > other cloud storage vendors leverage the same network protocols? > > Are there any patents that the IETF should be aware of, e.g. > ? > > -- Rich > > -----Original Message----- > From: Wesley Leggette [mailto:wleggette@cleversafe.com] > Sent: Thursday, January 14, 2010 11:03 PM > To: Song Haibin; Alexey Melnikov > Cc: IETF Apps Discuss; Woundy, Richard > Subject: Re: Application protocol for distributed storage > > > > > The DECADE work is interesting, but it is not specifically what we are > working on. Our system, I'm sure, uses some of the same > principals, but > we > are focusing on hosted systems. Sort of a "hosted P2P" if you will. > > So while our system [1] will address dynamic peer environments, it is > not > our main concern because our storage nodes are assumed to be available > in > the usual case. Instead, we are interested in using IDAs[2] to enhance > availability, reliability, and security. > > [1] http://www.cleversafe.com/ > > However, DECADE does seem very interesting. There are some > people in my > company that may be interested in participating in that if it gets > going. > > Wesley Leggette > Cleversafe, Inc. > > > On 1/14/10 21:41, "Song Haibin" wrote: > > > Hi Wesley, > > > > I'm very glad to get this email from Alexey. The link below is about > the BOF > > information at IETF 76 meeting. > > http://trac.tools.ietf.org/bof/trac/wiki/decade > > > > And we have been trying to narrow down the protocol scope > to resource > > control and negotiation of transport protocol as we have > discussed in > the > > mailing list. You could read about the latest thread here: > > > http://www.ietf.org/mail-archive/web/decade/current/threads.ht > ml#00106. > > > > Please let me know if it is the work that you are interested. > > > > Xie Xie, > > Haibin > > > > > >> -----Original Message----- > >> From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] > >> Sent: Friday, January 15, 2010 7:05 AM > >> To: Wesley Leggette > >> Cc: apps-discuss@ietf.org; 'Woundy, Richard'; Song Haibin > >> Subject: Re: Application protocol for distributed storage > >> > >> Wesley Leggette wrote: > >> > >>> Hello, > >>> > >>> > >> Hi Wesley, > >> > >>> My company is interested in submitting an I-D for our network > >>> distributed storage protocol. At this point, we're thinking > >> of dividing > >>> our efforts into multiple parts: > >>> > >>> * An on-the-wire application protocol from client to storage > servers. > >>> * A security protocol. > >>> * A data processing method and storage format for client > >> data stored on > >>> storage servers. > >>> > >>> I'm not entirely clear which working group(s) I should > >> attempt to work with. > >>> Any pointers would be helpful. > >>> > >>> > >>> Our application and products as a whole get into the > "cloud storage" > >>> area, but we would like to focus on a smaller subset (just > >> the network > >>> protocol) to begin with. However, if there are any working groups > >>> within IETF that focus on remote or distributed storage that > >> would be > >>> interesting to know as well. > >>> > >>> > >> This looks similar to the DECADE BOF that IETF had in > >> Hiroshima. I am hoping this would become a WG soon. > >> (I've CCed the BOF co-chairs). > >> > >> Regards, > >> Alexey > >> > >> -- > >> IETF Application Area Director, > >> Internet Messaging Team Lead, > >> JID: same as my email address > >> > >> > > > > > > From wleggette@cleversafe.com Thu Jan 21 08:22:40 2010 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 6788D28C184 for ; Thu, 21 Jan 2010 08:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[AWL=-0.743, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_URI_REPLICA=1.634] 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 Z3Bq5wJ1Tg2C for ; Thu, 21 Jan 2010 08:22:39 -0800 (PST) Received: from p01c12o144.mxlogic.net (p01c12o144.mxlogic.net [208.65.145.67]) by core3.amsl.com (Postfix) with ESMTP id 6B24528C168 for ; Thu, 21 Jan 2010 08:22:38 -0800 (PST) Received: from unknown [216.166.12.178] (EHLO p01c12o144.mxlogic.net) by p01c12o144.mxlogic.net(mxl_mta-6.4.0-2) with ESMTP id a4f785b4.a6ea9b90.13151.00-428.27425.p01c12o144.mxlogic.net (envelope-from ); Thu, 21 Jan 2010 09:22:34 -0700 (MST) X-MXL-Hash: 4b587f4a5bdd5e5f-f478162c488ff567c4002ace44aec5739a2d2550 Received: from unknown [216.166.12.178] by p01c12o144.mxlogic.net(mxl_mta-6.4.0-2) with SMTP id c3f785b4.0.12387.00-013.27283.p01c12o144.mxlogic.net (envelope-from ); Thu, 21 Jan 2010 09:22:32 -0700 (MST) X-MXL-Hash: 4b587f486bf45f63-a41810810f515adcfafa382d1c657adcd290b846 Received: from AUSP01VMBX09.collaborationhost.net ([10.2.8.161]) by AUSP01MHUB04.collaborationhost.net ([10.2.0.189]) with mapi; Thu, 21 Jan 2010 10:22:00 -0600 From: Wesley Leggette To: Song Haibin , DECADE Date: Thu, 21 Jan 2010 10:21:57 -0600 Thread-Topic: [decade] Related problem statement Thread-Index: AcqaAijiubwjSFr1y02O0rY4K1dGMQAOe+MAAB5wYaQ= Message-ID: In-Reply-To: <00c401ca9a6a$ff7837c0$180ca40a@china.huawei.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010011101)] X-MAIL-FROM: X-SOURCE-IP: [216.166.12.178] X-AnalysisOut: [v=1.0 c=1 a=N0rcUYRaQg3G+2kUXxmxxA==:17 a=i0EeH86SAAAA:8 a] X-AnalysisOut: [=lxMegurXAAAA:8 a=NxH_6L17AAAA:8 a=48vgC7mUAAAA:8 a=sQnJkf] X-AnalysisOut: [nzXYKQtxqQEx0A:9 a=IHkKdYW3wpGVuADqlREA:7 a=sW3zvD3DWrg2LE] X-AnalysisOut: [ThvZw-KJCKAv4A:4 a=hPjdaMEvmhQA:10 a=lZB815dzVvQA:10] Subject: Re: [decade] Related problem statement X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 16:22:40 -0000 Haibin, I look forward to your response to our problem statement, which I hope to finish up this week. I should note that at this point, we are interested mainly in a signaling protocol as well, though the fact that it has to work over various transpor= t layer streams may make the requirements too different. With our system, we found that the difficultly is not in the use of Erasure Codes (that part is well known), but in the constraints imposed by a distributed system when you need to write large objects with many related parts. This is where a good transaction and revision model have been important.=20 I will go into more detail in the problem statement, but I just want to not= e that we feel that these constraints exist regardless of whether erasure codes, wholesale replication, or data splitting (which as you have previously noted is typical of most P2P applications) is used. The problem has not been addressed as of yet because most P2P systems are "single-seed/read-only", where an object is only transmitted by request fro= m the receiver regardless of it origin, and is only advertised when the objec= t is completely available from at least that seed origin. In a system where objects are originated by a transmitter they may be advertised before they are completely written. We feel that it is important ensure that some guarantees can be made with regards to multi-part object completeness. Even if we cannot converge our two problems, you may want to take some of this into account in the DECADE design. Wesley On 1/21/10 01:26, "Song Haibin" wrote: > Hi Wesley, >=20 > After reading some materials from your company's websit. From > http://www.cleversafe.com/vision/object-storage > http://www.cleversafe.com/vision/Replication_vs._Information_Dispersal > http://www.cleversafe.org/dispersed-storage/idas > http://www.cleversafe.com/vision/Dispersed_Data_Archiving_Top-10-Features >=20 > I think the product of your company is using Erasure Codes to store conte= nts > and using p2p technologies to organize contents and in-network storage > devices. So I believe it is trying to solve some different problems than > DECADE's. Because we don't want to design a whole system but only a > signaling protocol between p2p application and in-network storage for > resource control and indication of underlying data access/transport > protocols. I'm happy to read your problem statement draft after you finis= h > it. But I don't know if there is opportunity to converge these two differ= ent > problem statements. >=20 > As for the status, we held a bar BOF at IETF 75, and a BOF at IETF 76. We > are trying to clarifing the scope and looking forward to form an working > group. >=20 > Thank you, > Haibin >=20 >=20 >=20 >=20 >> -----Original Message----- >> From: decade-bounces@ietf.org >> [mailto:decade-bounces@ietf.org] On Behalf Of Wesley Leggette >> Sent: Thursday, January 21, 2010 2:56 AM >> To: decade@ietf.org >> Subject: [decade] Related problem statement >>=20 >> Hello, >>=20 >> My company has a distributed storage system product which >> uses Erasure Codes to store data reliably. We are hoping to >> standardize our protocols and data formats. I recently sent >> out a question tot he apps discuss list asking if anybody was >> working on something similar, and DECADE was pointed out to me. >>=20 >> Our problem and requirements are slightly different than >> those pointed out in your problem statement. Specifically, we >> are more of a "hosted P2P" >> environment. In effect, this means that some of the dynamic >> content lookup is a bit simpler in the initial implementation >> of our system (because the data is stored on fixed nodes run >> by one or more hosting providers). We also originally >> envisioned (and have currently implemented) an application >> layer protocol for data transport, though the possibility of >> a "transport agnostic" protocol which could be encapsulated >> in P2P application protocols is intriguing. >>=20 >> I think that there could be a lot of overlap between the >> requirements we are facing and the requirements which will >> have to be addressed by DECADE. >>=20 >> I will be shortly submitting a problem statement of our own. >> Once I do, I would like to invite you to read it and let me >> know if there would be any interest in converging our two problems. >>=20 >>=20 >> In the mean time, what is the status of this body? I see from >> the schedule that you have an initial charter proposal. Has >> there been much progress since then? >>=20 >> Wesley Leggette >>=20 >> _______________________________________________ >> decade mailing list >> decade@ietf.org >> https://www.ietf.org/mailman/listinfo/decade >>=20 >=20 >=20 From melodysong@huawei.com Thu Jan 21 22:13:28 2010 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 AF6813A67D1 for ; Thu, 21 Jan 2010 22:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.447 X-Spam-Level: X-Spam-Status: No, score=-0.447 tagged_above=-999 required=5 tests=[AWL=0.518, BAYES_00=-2.599, SARE_URI_REPLICA=1.634] 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 bCHa2L-b7y8b for ; Thu, 21 Jan 2010 22:13:23 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 48A663A679C for ; Thu, 21 Jan 2010 22:13:21 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWM004WSXA3MB@szxga01-in.huawei.com> for decade@ietf.org; Fri, 22 Jan 2010 14:13:15 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWM00JEZXA3PN@szxga01-in.huawei.com> for decade@ietf.org; Fri, 22 Jan 2010 14:13:15 +0800 (CST) Received: from s64081a ([10.164.12.24]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KWM007DGXA0UT@szxml04-in.huawei.com> for decade@ietf.org; Fri, 22 Jan 2010 14:13:15 +0800 (CST) Date: Fri, 22 Jan 2010 14:13:12 +0800 From: Song Haibin In-reply-to: To: 'Wesley Leggette' , 'DECADE' Message-id: <00b101ca9b29$f9fc5af0$180ca40a@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: AcqaAijiubwjSFr1y02O0rY4K1dGMQAOe+MAAB5wYaQAG/SjcA== Subject: Re: [decade] Related problem statement X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 06:13:29 -0000 >In a system where > objects are originated by a transmitter they may be > advertised before they are completely written. We feel that > it is important ensure that some guarantees can be made with > regards to multi-part object completeness. > I'm not sure if you mean the in-network storage can advertise an object and at the same time download multiple parts of this object from multiple peers dynamically, or redirect the peers to get other parts from other addresses? Usually we want the problem to be narrow scoped and I guess we don't want to broaden DECADE's scope to that way. Haibin > -----Original Message----- > From: Wesley Leggette [mailto:wleggette@cleversafe.com] > Sent: Friday, January 22, 2010 12:22 AM > To: Song Haibin; DECADE > Subject: Re: [decade] Related problem statement > > > Haibin, > > I look forward to your response to our problem statement, > which I hope to finish up this week. > > I should note that at this point, we are interested mainly in > a signaling protocol as well, though the fact that it has to > work over various transport layer streams may make the > requirements too different. > > With our system, we found that the difficultly is not in the > use of Erasure Codes (that part is well known), but in the > constraints imposed by a distributed system when you need to > write large objects with many related parts. This is where a > good transaction and revision model have been important. > > I will go into more detail in the problem statement, but I > just want to note that we feel that these constraints exist > regardless of whether erasure codes, wholesale replication, > or data splitting (which as you have previously noted is > typical of most P2P applications) is used. > > The problem has not been addressed as of yet because most P2P > systems are "single-seed/read-only", where an object is only > transmitted by request from the receiver regardless of it > origin, and is only advertised when the object is completely > available from at least that seed origin. In a system where > objects are originated by a transmitter they may be > advertised before they are completely written. We feel that > it is important ensure that some guarantees can be made with > regards to multi-part object completeness. > > Even if we cannot converge our two problems, you may want to > take some of this into account in the DECADE design. > > Wesley > > > > On 1/21/10 01:26, "Song Haibin" wrote: > > > Hi Wesley, > > > > After reading some materials from your company's websit. From > > http://www.cleversafe.com/vision/object-storage > > > http://www.cleversafe.com/vision/Replication_vs._Information_Dispersal > > http://www.cleversafe.org/dispersed-storage/idas > > > http://www.cleversafe.com/vision/Dispersed_Data_Archiving_Top-10-Featu > > res > > > > I think the product of your company is using Erasure Codes to store > > contents and using p2p technologies to organize contents and > > in-network storage devices. So I believe it is trying to solve some > > different problems than DECADE's. Because we don't want to design a > > whole system but only a signaling protocol between p2p > application and > > in-network storage for resource control and indication of > underlying > > data access/transport protocols. I'm happy to read your problem > > statement draft after you finish it. But I don't know if there is > > opportunity to converge these two different problem statements. > > > > As for the status, we held a bar BOF at IETF 75, and a BOF > at IETF 76. > > We are trying to clarifing the scope and looking forward to form an > > working group. > > > > Thank you, > > Haibin > > > > > > > > > >> -----Original Message----- > >> From: decade-bounces@ietf.org > >> [mailto:decade-bounces@ietf.org] On Behalf Of Wesley Leggette > >> Sent: Thursday, January 21, 2010 2:56 AM > >> To: decade@ietf.org > >> Subject: [decade] Related problem statement > >> > >> Hello, > >> > >> My company has a distributed storage system product which uses > >> Erasure Codes to store data reliably. We are hoping to standardize > >> our protocols and data formats. I recently sent out a > question tot he > >> apps discuss list asking if anybody was working on > something similar, > >> and DECADE was pointed out to me. > >> > >> Our problem and requirements are slightly different than those > >> pointed out in your problem statement. Specifically, we > are more of a > >> "hosted P2P" > >> environment. In effect, this means that some of the > dynamic content > >> lookup is a bit simpler in the initial implementation of > our system > >> (because the data is stored on fixed nodes run by one or > more hosting > >> providers). We also originally envisioned (and have currently > >> implemented) an application layer protocol for data > transport, though > >> the possibility of a "transport agnostic" protocol which could be > >> encapsulated in P2P application protocols is intriguing. > >> > >> I think that there could be a lot of overlap between the > requirements > >> we are facing and the requirements which will have to be > addressed by > >> DECADE. > >> > >> I will be shortly submitting a problem statement of our own. > >> Once I do, I would like to invite you to read it and let > me know if > >> there would be any interest in converging our two problems. > >> > >> > >> In the mean time, what is the status of this body? I see from the > >> schedule that you have an initial charter proposal. Has there been > >> much progress since then? > >> > >> Wesley Leggette > >> > >> _______________________________________________ > >> decade mailing list > >> decade@ietf.org > >> https://www.ietf.org/mailman/listinfo/decade > >> > > > > > > From richard.alimi@yale.edu Fri Jan 22 13:58:39 2010 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 22B0B3A6881 for ; Fri, 22 Jan 2010 13:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 V+0zz-Ggn5+2 for ; Fri, 22 Jan 2010 13:58:38 -0800 (PST) Received: from pantheon-po29.its.yale.edu (pantheon-po29.its.yale.edu [130.132.50.124]) by core3.amsl.com (Postfix) with ESMTP id F28273A6774 for ; Fri, 22 Jan 2010 13:58:37 -0800 (PST) Received: from poweredge.velvetsea.net (adsl-69-183-234-134.adsl.snet.net [69.183.234.134] (may be forged)) (authenticated bits=0) by pantheon-po29.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id o0MLwQGG019252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 22 Jan 2010 16:58:29 -0500 Received: from p4p-7.localnet (p4p-7.cs.yale.edu [128.36.233.97]) by poweredge.velvetsea.net (Postfix) with ESMTPSA id 5CD4F42401D for ; Fri, 22 Jan 2010 16:58:26 -0500 (EST) From: Richard Alimi Date: Fri, 22 Jan 2010 16:58:24 -0500 User-Agent: KMail/1.12.4 (Linux/2.6.31-gentoo-r6; KDE/4.3.4; x86_64; ; ) MIME-Version: 1.0 X-Length: 6585 X-UID: 145 To: decade@ietf.org Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201001221658.24381.richard.alimi@yale.edu> X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) Subject: [decade] Updated DECADE Charter 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, 22 Jan 2010 21:58:39 -0000 Hi All, We have been working on a new charter with a refined scope and incorporating past discussion on the mailing list. It would be wonderful to hear comments on the new proposed charter. ======================================================================== DECoupled Application Data Enroute Description of Working Group: Peer-to-Peer (P2P) applications, including both P2P streaming and P2P file- sharing applications, make up a large fraction of traffic in the Internet today. One way to reduce access network and/or cross-domain bandwidth usage by P2P applications is to introduce storage capabilities in the networks. Allowing P2P applications to store and retrieve data from inside networks can reduce traffic on the last-mile uplink, as well as backbone and transit links. Existing P2P caches often implement the specific P2P application protocols to operate transparently or act as super peers to provide in-network storage. However, this approach poses challenges to both P2P cache vendors and P2P application developers. For P2P cache vendors, the challenge is to support a variety of exisiting and evolving protocols. For P2P applications, closed P2P caching systems limit effective utilization of in-network storage. Some P2P protocols may be entirely unsupported, and applications may be better-equipped to decide how in-network storage is used to meet their specific requirements (e.g., data placement, access control and resource control). Both of these challenges can be effectively addressed by using an open, standard protocol to access in-network storage. P2P applications can store and retrieve content in the in-network storage, as well as control resources (e.g., bandwidth, connections) consumed by peers in a P2P application. As a simple example, a peer can choose to store content in the in-network storage, and direct other peers to retrieve from that location, reducing last-mile link usage. Though there are existing data access protocols (e.g., HTTP, NFS, WebDAV), they lack capabilities needed when applied in this context. The Working Group (WG) will design and specify a standard protocol for P2P applications to utilize in-network storage. The protocol will include operations for a P2P application to (1) store, retrieve, and manage data, (2) specify access control for storing and retrieving data suitable for a P2P environment with peers across multiple administrative and security domains, and (3) indicate resource control policies for storing and retrieving data. The WG will leverage existing IETF protocols where possible, in particular for storing, retrieving, and managing data. This WG will focus mainly on the protocol between the in-network storage and P2P applications. The protocol will be focused on P2P applications, though it may also be used in other types of applications. The WG will focus on the following work items: - A "problem statement" document. This document provides a description of the problem and common terminology. - A requirements document. This document lists the requirements for the in-network storage service (e.g., supported operations) and the protocol to support it. - A survey document. This document will survey existing related mechanisms and protocols (e.g., HTTP, NFS, and WebDAV), and evaluate their applicability and effectiveness. - A signaling protocol for storing, retrieving, and managing data as well as specifying both access control and resource control policies in the in-network storage pertaining to that data. Data storage, retrieval, and management may be provided by an existing IETF protocol. If the underlying protocol does not support certain data management operations, DECADE may seek to define such extensions and present them to the respective working groups or create an Individual Submission if no active working group exists. This group may also create a profile of necessary operations from an existing IETF protocol to reduce the complexity and software footprint of a compliant implementation. The WG will not limit itself to a single underlying protocol since different underlying protocols may have varying implementation costs and performance tradeoffs. To keep interoperability manageable, a small number of specific, targeted, underlying protocols will be used. NFS and WebDAV are initial targets and others may be incorporated with WG consensus. - An informational document describing the integration of DECADE with existing P2P applications (e.g., integration with BitTorrent). The following issues are not considered in the current scope of the WG: - Copyright protected or illegal content For example, one possibility is that that an in-network storage system may have system-wide ingress and egress filters to implement policies related to copyrighted and illegal content. This is outside the scope of this working group. - Locating the "best" in-network storage location from which to retrieve content if there are more than one location can provide the same content. - Developing a new protocol to deliver content between P2P application and in-network storage. Goals and Milestones: May 2010 Working Group Last Call for problem statement Aug 2010 Submit problem statement to IESG as Informational Aug 2010 Working Group Last Call for requirements document Feb 2011 Submit requirements document to IESG as Informational May 2011 Working Group Last Call for survey document Aug 2011 Working Group Last Call for in-network storage access protocol Aug 2011 Submit survey document to IESG as Informational Nov 2011 Submit in-network storage access protocol to IESG as Proposed Standard ======================================================================== Thanks! -- Richard Alimi Department of Computer Science Yale University From richard_woundy@cable.comcast.com Fri Jan 22 16:17:33 2010 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 6C23028C0D8 for ; Fri, 22 Jan 2010 16:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.312 X-Spam-Level: X-Spam-Status: No, score=-4.312 tagged_above=-999 required=5 tests=[AWL=-3.851, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvMoKuHuuHi0 for ; Fri, 22 Jan 2010 16:17:32 -0800 (PST) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 155E328C0E1 for ; Fri, 22 Jan 2010 16:17:32 -0800 (PST) Received: from ([10.52.116.30]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.86102128; Fri, 22 Jan 2010 19:17:11 -0500 Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Jan 2010 19:17:12 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 x-cr-puzzleid: {0E0E094C-F75F-4B1A-8B7C-8688FAE0873F} MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA9BC1.68AAF1C8" x-cr-hashedpuzzle: AQAf BZDi CQNt DU+0 DYe2 Dl3H FUhe Fb4K GqxE GrVl HPPu JcXQ Jno2 KyzV Lmbv LwFR; 1; ZABlAGMAYQBkAGUAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {0E0E094C-F75F-4B1A-8B7C-8688FAE0873F}; cgBpAGMAaABhAHIAZABfAHcAbwB1AG4AZAB5AEAAYwBhAGIAbABlAC4AYwBvAG0AYwBhAHMAdAAuAGMAbwBtAA==; Sat, 23 Jan 2010 00:17:09 GMT; UgBGAEMAIABzAGUAcgBpAGUAcwAgAGYAbwByACAATgBGAFMAIAB2ADQALgAxACAAagB1AHMAdAAgAHAAdQBiAGwAaQBzAGgAZQBkAA== Content-class: urn:content-classes:message Date: Fri, 22 Jan 2010 19:17:09 -0500 Message-ID: <8A82D1BFEDDE7E4597978355239BBBCBB58DC3@PACDCEXCMB06.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC series for NFS v4.1 just published Thread-Index: AcqbwWbk4XLuXW2hR9q/qD9jkxsqsQ== From: "Woundy, Richard" To: X-OriginalArrivalTime: 23 Jan 2010 00:17:12.0320 (UTC) FILETIME=[68D40800:01CA9BC1] Subject: [decade] RFC series for NFS v4.1 just published 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, 23 Jan 2010 00:17:33 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA9BC1.68AAF1C8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, =20 Since we are seriously looking at NFS as a candidate data access and management protocol for Decade, we should all be aware of the latest NFS v4.1 RFCs published by the nfsv4 working group just this week: =20 5661 =20 Network File System (NFS) Version 4 Minor Version 1 Protocol S. Shepler, M. Eisler, D. Noveck [ January 2010 ] (TXT =3D 1517771) (Status: = PROPOSED STANDARD) (Stream: IETF, Area: tsv, WG: nfsv4)=20 5662 =20 Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description S. Shepler, M. Eisler, D. Noveck [ January 2010 ] (TXT =3D 126581) (Status: PROPOSED STANDARD) (Stream: IETF, Area: tsv, WG: nfsv4)=20 5663 =20 Parallel NFS (pNFS) Block/Volume Layout D. Black, S. Fridella, J. Glasgow [ January 2010 ] (TXT =3D 68571) (Status: PROPOSED STANDARD) (Stream: IETF, Area: tsv, WG: nfsv4)=20 5664 =20 Object-Based Parallel NFS (pNFS) Operations B. Halevy, B. Welch, J. Zelenka [ January 2010 ] (TXT =3D 78200) (Status: PROPOSED STANDARD) (Stream: IETF, Area: tsv, WG: nfsv4)=20 5665 =20 IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats M. Eisler [ January 2010 ] (TXT =3D 28706) (Updates RFC1833 ) (Status: PROPOSED STANDARD) (Stream: IETF, Area: tsv, WG: nfsv4)=20 5666 =20 Remote Direct Memory Access Transport for Remote Procedure Call T. Talpey, B. Callaghan [ January 2010 ] (TXT =3D 83728) (Status: PROPOSED STANDARD) (Stream: IETF, Area: tsv, WG: nfsv4)=20 5667 =20 Network File System (NFS) Direct Data Placement T. Talpey, B. Callaghan [ January 2010 ] (TXT =3D 83728) (Status: PROPOSED STANDARD) (Stream: IETF, Area: tsv, WG: nfsv4)=20 =20 -- Rich ------_=_NextPart_001_01CA9BC1.68AAF1C8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

Since we are seriously looking at NFS as a = candidate data access and management protocol for Decade, we should all be aware of the = latest NFS v4.1 RFCs published by the nfsv4 working group just this = week:

 

5661

Network File System (NFS) Version 4 Minor Version = 1 Protocol S. Shepler, M. Eisler, D. Noveck [ January 2010 ] (TXT =3D = 1517771) (Status: PROPOSED STANDARD) (Stream: IETF, Area: tsv, WG: nfsv4) =

5662

Network File System (NFS) Version 4 Minor Version = 1 External Data Representation Standard (XDR) Description S. Shepler, M. Eisler, D. Noveck [ January 2010 ] (TXT =3D 126581) (Status: PROPOSED = STANDARD) (Stream: IETF, Area: tsv, WG: nfsv4)

5663

Parallel NFS (pNFS) Block/Volume Layout D. Black, = S. Fridella, J. Glasgow [ January 2010 ] (TXT =3D 68571) (Status: = PROPOSED STANDARD) (Stream: IETF, Area: tsv, WG: nfsv4)

5664

Object-Based Parallel NFS (pNFS) Operations B. = Halevy, B. Welch, J. Zelenka [ January 2010 ] (TXT =3D 78200) (Status: PROPOSED = STANDARD) (Stream: IETF, Area: tsv, WG: nfsv4)

5665

IANA Considerations for Remote Procedure Call = (RPC) Network Identifiers and Universal Address Formats M. Eisler [ January = 2010 ] (TXT =3D 28706) (Updates RFC1833) (Status: PROPOSED STANDARD) (Stream: = IETF, Area: tsv, WG: nfsv4)

5666

Remote Direct Memory Access Transport for Remote = Procedure Call T. Talpey, B. Callaghan [ January 2010 ] (TXT =3D 83728) (Status: = PROPOSED STANDARD) (Stream: IETF, Area: tsv, WG: nfsv4)

5667

Network File System (NFS) Direct Data Placement = T. Talpey, B. Callaghan [ January 2010 ] (TXT =3D 83728) (Status: PROPOSED = STANDARD) (Stream: IETF, Area: tsv, WG: nfsv4)

 

-- Rich

------_=_NextPart_001_01CA9BC1.68AAF1C8-- From davidbryan@gmail.com Tue Jan 26 11:39:24 2010 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 423713A68AD for ; Tue, 26 Jan 2010 11:39:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9PMHtdlMjpv for ; Tue, 26 Jan 2010 11:39:23 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id D16453A6999 for ; Tue, 26 Jan 2010 11:39:19 -0800 (PST) Received: by gxk28 with SMTP id 28so4186391gxk.9 for ; Tue, 26 Jan 2010 11:39:28 -0800 (PST) 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=aYKcylsl1iMfF9ci6QcWpxlr6Pj06Waqd/mo9g5Gl9s=; b=N9qXczvs9KgVCdrwiuimcR8kfA2H370KJhNs3RjMR0Y4tqUIYirkaSItneVjhNwrlU 8eGBEUmft9An4N+O4ZOBy7us1le0tGi71ttEZlrW3uoJN2aOQkM/QfBFGpqJYc/ihZ98 zSEdIDLJIT6o6rQ/pjNrcYvh8gXNNMkkYHsnQ= 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=Oy6PtwjINJ50U2xg+ThSj4rHWpuK0sxrCv0rKHjEFJs04nuyRWYpxC/hFRS00KXqru 8DHMiNQzkUfrsBa7vrR5PFhh5vqXUhiYEsdjXZhsHYKENY5EdiQ4Rg5F9v6yicUx3sU5 72igjDLc3THWA2v2SQBcMww0EgLl2U+NhvDkg= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.150.209.16 with SMTP id h16mr11212913ybg.51.1264534738503; Tue, 26 Jan 2010 11:38:58 -0800 (PST) In-Reply-To: <201001221658.24381.richard.alimi@yale.edu> References: <201001221658.24381.richard.alimi@yale.edu> Date: Tue, 26 Jan 2010 14:38:58 -0500 X-Google-Sender-Auth: 683f93a4459980c6 Message-ID: <8b2769931001261138u43e6222ifa38d3cda3a258e6@mail.gmail.com> From: "David A. Bryan" To: Richard Alimi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: decade@ietf.org Subject: Re: [decade] Updated DECADE Charter 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, 26 Jan 2010 19:39:24 -0000 First of all, thanks to the folks working to get the charter put together. I think this starting to get quite a bit closer to what we need. A few thoughts, as well as some nits/editorial comments: Overall, while much better, there is still a bit of lack of clarity about what is being developed and what is definitely out of scope from a protocol perspective. I think the text is good that says we will try to re-use something (NFS, WebDav, etc.), for example, in para 4 it says that the WG will design a protocol that "leverage existing IETF protocols where possible, in particular for storing retrieving and managing data". However, I think folks could be confused when they then go on to read the third point for out of scope items is developing a new protocol to deliver content. My understanding is that there may be new work on a protocol to specify policies, and provide control messages and signaling around the transfers (possibly again reusing/extending or incoprorating some existing protocols), but that we would definitely reuse something for the actual transport, hence the third bullet in the out of scope items. Similarly, the last sentence in para 3 could be read to imply we can't reuse HTTP, NFS, etc., when I *believe* the intent is to note that if they are reused, they may need to be extended or used as a part of a solution. I think we need a bit more clarity to distinguish between where we may reuse or may develop new (access control, resource control, etc.), and where we are definitely using existing (actual transport, from my recollection) and make that a bit more crisp for a newcomer to this group. The last two sentences in para 2, when read together, read very oddly: "For P2P applications, closed P2P caching systems limit effective utilization of in-network storage. P2P protocols may be entirely unsupported, and applications may be better-equipped to decide how in-network storage is used to meet their specific requirements (e.g., data placement, access control and resource control)." maybe this? "For P2P applications, closed P2P caching systems limit effective utilization of in-network storage. Some P2P protocols may be entirely unsupported by a particular caching system. Additionally, applications may be better-equipped to decide how in-network storage is used to meet their specific requirements (e.g., data placement, access control and resource control)." In paragraph 4, I think maybe we are missing a word in this sentence: "...(2) specify access control for storing and retrieving data suitable for a P2P environment ..." access control settings? values? The last sentence in the fourth WG item is a bit unclear as well: "This group may also create a profile of necessary operations from an existing IETF protocol to reduce the complexity and software footprint of a compliant implementation." I think we should be clear about what we mean by compliant implementation here (i.e., compliant with the existing protocol or with DECADE). I think we mean a compliant DECADE implementation. As always, goals and milestones are always wild guesses. Spoken as someone who chairs another group that currently appears to have significantly expired milestones (now that I noticed, guess I better go fix that...oops), these seem really, really aggressive... Overall, I think this is getting much closer to ready. Great job, and looking forward to hearing comments from others. David On Fri, Jan 22, 2010 at 4:58 PM, Richard Alimi wro= te: > Hi All, > > We have been working on a new charter with a refined scope and incorporat= ing > past discussion on the mailing list. =A0It would be wonderful to hear com= ments > on the new proposed charter. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DECoupled Application Data Enroute > > Description of Working Group: > > Peer-to-Peer (P2P) applications, including both P2P streaming and P2P fil= e- > sharing applications, make up a large fraction of traffic in the Internet > today. One way to reduce access network and/or cross-domain bandwidth usa= ge by > P2P applications is to introduce storage capabilities in the networks. > Allowing P2P applications to store and retrieve data from inside networks= can > reduce traffic on the last-mile uplink, as well as backbone and transit l= inks. > > Existing P2P caches often implement the specific P2P application protocol= s to > operate transparently or act as super peers to provide in-network storage= . > However, this approach poses challenges to both P2P cache vendors and P2P > application developers. For P2P cache vendors, the challenge is to suppor= t a > variety of exisiting and evolving protocols. For P2P applications, closed= P2P > caching systems limit effective utilization of in-network storage. Some P= 2P > protocols may be entirely unsupported, and applications may be better-equ= ipped > to decide how in-network storage is used to meet their specific requireme= nts > (e.g., data placement, access control and resource control). > > Both of these challenges can be effectively addressed by using an open, > standard protocol to access in-network storage. P2P applications can stor= e and > retrieve content in the in-network storage, as well as control resources > (e.g., bandwidth, connections) consumed by peers in a P2P application. = =A0As a > simple example, a peer can choose to store content in the in-network stor= age, > and direct other peers to retrieve from that location, reducing last-mile= link > usage. =A0Though there are existing data access protocols (e.g., HTTP, NF= S, > WebDAV), they lack capabilities needed when applied in this context. > > The Working Group (WG) will design and specify a standard protocol for P2= P > applications to utilize in-network storage. =A0The protocol will include > operations for a P2P application to (1) store, retrieve, and manage data,= (2) > specify access control for storing and retrieving data suitable for a P2P > environment with peers across multiple administrative and security domain= s, > and (3) indicate resource control policies for storing and retrieving dat= a. > The WG will leverage existing IETF protocols where possible, in particula= r for > storing, retrieving, and managing data. > > This WG will focus mainly on the protocol between the in-network storage = and > P2P applications. =A0The protocol will be focused on P2P applications, th= ough it > may also be used in other types of applications. > > The WG will focus on the following work items: > > - A "problem statement" document. This document provides a description of= the > =A0problem and common terminology. > > - A requirements document. This document lists the requirements for the > =A0in-network storage service (e.g., supported operations) and the protoc= ol to > =A0support it. > > - A survey document. This document will survey existing related mechanism= s > =A0and protocols (e.g., HTTP, NFS, and WebDAV), and evaluate their > =A0applicability and effectiveness. > > - A signaling protocol for storing, retrieving, and managing data as well= as > =A0specifying both access control and resource control policies in the > =A0in-network storage pertaining to that data. =A0Data storage, retrieval= , and > =A0management may be provided by an existing IETF protocol. If the underl= ying > =A0protocol does not support certain data management operations, DECADE m= ay > =A0seek to define such extensions and present them to the respective work= ing > =A0groups or create an Individual Submission if no active working group e= xists. > =A0This group may also create a profile of necessary operations from an > =A0existing IETF protocol to reduce the complexity and software footprint= of a > =A0compliant implementation. > > =A0The WG will not limit itself to a single underlying protocol since dif= ferent > =A0underlying protocols may have varying implementation costs and perform= ance > =A0tradeoffs. To keep interoperability manageable, a small number of spec= ific, > =A0targeted, underlying protocols will be used. NFS and WebDAV are initia= l > =A0targets and others may be incorporated with WG consensus. > > - An informational document describing the integration of DECADE with exi= sting > =A0P2P applications (e.g., integration with BitTorrent). > > The following issues are not considered in the current scope of the WG: > > - Copyright protected or illegal content > =A0For example, one possibility is that that an in-network storage system= may > =A0have system-wide ingress and egress filters to implement policies rela= ted to > =A0copyrighted and illegal content. =A0This is outside the scope of this = working > =A0group. > > - Locating the "best" in-network storage location from which to retrieve > =A0content if there are more than one location can provide the same conte= nt. > > - Developing a new protocol to deliver content between P2P application an= d > =A0in-network storage. > > Goals and Milestones: > > May 2010 =A0Working Group Last Call for problem statement > Aug 2010 =A0Submit problem statement to IESG as Informational > Aug 2010 =A0Working Group Last Call for requirements document > Feb 2011 =A0Submit requirements document to IESG as Informational > May 2011 =A0Working Group Last Call for survey document > Aug 2011 =A0Working Group Last Call for in-network storage access protoco= l > Aug 2011 =A0Submit survey document to IESG as Informational > Nov 2011 =A0Submit in-network storage access protocol to IESG as Proposed > =A0 =A0 =A0 =A0 =A0Standard > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Thanks! > -- > Richard Alimi > Department of Computer Science > Yale University > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > From richard.alimi@yale.edu Tue Jan 26 12:27:27 2010 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 6E60128C0F6 for ; Tue, 26 Jan 2010 12:27:27 -0800 (PST) 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 Agf51gqxEFEa for ; Tue, 26 Jan 2010 12:27:25 -0800 (PST) Received: from pantheon-po33.its.yale.edu (pantheon-po33.its.yale.edu [130.132.50.94]) by core3.amsl.com (Postfix) with ESMTP id B98E828C0F2 for ; Tue, 26 Jan 2010 12:27:24 -0800 (PST) Received: from poweredge.velvetsea.net (adsl-69-183-234-134.adsl.snet.net [69.183.234.134] (may be forged)) (authenticated bits=0) by pantheon-po33.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id o0QKRPnj001440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 26 Jan 2010 15:27:25 -0500 Received: from p4p-7.localnet (p4p-7.cs.yale.edu [128.36.233.97]) by poweredge.velvetsea.net (Postfix) with ESMTPSA id 5545D42401D; Tue, 26 Jan 2010 15:27:25 -0500 (EST) From: Richard Alimi To: "David A. Bryan" Date: Tue, 26 Jan 2010 15:27:24 -0500 User-Agent: KMail/1.12.4 (Linux/2.6.31-gentoo-r6; KDE/4.3.4; x86_64; ; ) References: <201001221658.24381.richard.alimi@yale.edu> <8b2769931001261138u43e6222ifa38d3cda3a258e6@mail.gmail.com> In-Reply-To: <8b2769931001261138u43e6222ifa38d3cda3a258e6@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201001261527.24439.richard.alimi@yale.edu> X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) Cc: decade@ietf.org Subject: Re: [decade] Updated DECADE Charter 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, 26 Jan 2010 20:27:27 -0000 Hi David, First of all, thank you very much for taking the time to read the new proposed charter and provide feedback. Responses inline below: > Overall, while much better, there is still a bit of lack of clarity > about what is being developed and what is definitely out of scope from > a protocol perspective. I think the text is good that says we will try > to re-use something (NFS, WebDav, etc.), for example, in para 4 it > says that the WG will design a protocol that "leverage existing IETF > protocols where possible, in particular for storing retrieving and > managing data". However, I think folks could be confused when they > then go on to read the third point for out of scope items is > developing a new protocol to deliver content. > > My understanding is that there may be new work on a protocol to > specify policies, and provide control messages and signaling around > the transfers (possibly again reusing/extending or incoprorating some > existing protocols), but that we would definitely reuse something for > the actual transport, hence the third bullet in the out of scope > items. Your understanding of the intent is correct. The intended meaning of the last "out of scope" item was to underline the fact that we don't want to design another NFS or WebDAV for transferring data, but instead re-use them. Perhaps it could be clarified as: "Developing a new protocol for data transport between P2P applications and in-network storage." Do you think this clarifies it enough? > Similarly, the last sentence in para 3 could be read to imply > we can't reuse HTTP, NFS, etc., when I *believe* the intent is to note > that if they are reused, they may need to be extended or used as a > part of a solution. I see the ambiguity here. Perhaps that sentence can be made more explicit by saying: Though there are existing data access protocols (e.g., HTTP, NFS, WebDAV), they currently lack capabilities needed when applied in this context. As part of DECADE, we aim to fill in the gaps and make certain protocols usable in this context. > I think we need a bit more clarity to distinguish > between where we may reuse or may develop new (access control, > resource control, etc.), and where we are definitely using existing > (actual transport, from my recollection) and make that a bit more > crisp for a newcomer to this group. In regards to identifying where we may need to extend the underlying protocol, we currently we have this text: If the underlying protocol does not support certain data management operations, DECADE may seek to define such extensions and present them to the respective working groups or create an Individual Submission if no active working group exists. We are operating under the assumption that the underlying protocol will already support read/write (i.e., data transport), and may also have some operations for managing whatever data is currently stored. However, there may be certain resource management operations that are not currently present. This is why we felt it necessary to call out that we may need to extend the set of operations in the underlying protocol, and provide an avenue for doing that. [As a side note, re-reading the existing text, I believe that "data management" should be changed to "resource management" since there may exist a need to manage resources other than data (e.g., bandwidth, connections).] To make this distinction more clear, perhaps we can say something like: ... The underlying protocol will be used wherever possible to support DECADE's required operations. It is assumed that the underlying protocol already supports data transport for reading from and writing to in-network storage. If the existing underlying protocol does not support certain resource management operations, DECADE may seek to define such extensions and present them to the respective working groups or create an Individual Submission if no active working group exists. ... > The last two sentences in para 2, when read together, read very oddly: > > "For P2P applications, closed P2P caching systems limit effective > utilization of in-network storage. P2P protocols may be entirely > unsupported, and applications may be better-equipped to decide how > in-network storage is used to meet their specific requirements (e.g., > data placement, access control and resource control)." > > maybe this? > > "For P2P applications, closed P2P caching systems limit effective > utilization of in-network storage. Some P2P protocols may be entirely > unsupported by a particular caching system. Additionally, applications > may be better-equipped to decide how in-network storage is used to > meet their specific requirements (e.g., data placement, access control > and resource control)." This makes sense. This can be incorporated in the next revision. > In paragraph 4, I think maybe we are missing a word in this sentence: > > "...(2) specify access control for storing and retrieving data > suitable for a P2P environment ..." > > access control settings? values? "policies" may characterize this better. This can be added. > > The last sentence in the fourth WG item is a bit unclear as well: > > "This group may also create a profile of necessary operations from an > existing IETF protocol to reduce the complexity and software footprint > of a compliant implementation." > > I think we should be clear about what we mean by compliant > implementation here (i.e., compliant with the existing protocol or > with DECADE). I think we mean a compliant DECADE implementation. Yes, we do mean a compliant DECADE implementation. This can be clarified. > As always, goals and milestones are always wild guesses. Spoken as > someone who chairs another group that currently appears to have > significantly expired milestones (now that I noticed, guess I better > go fix that...oops), these seem really, really aggressive... > > Overall, I think this is getting much closer to ready. Great job, and > looking forward to hearing comments from others. We are also looking forward to hearing comments from others as well :) -- Richard Alimi Department of Computer Science Yale University From davidbryan@gmail.com Tue Jan 26 12:48:22 2010 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 69C3228C0F4 for ; Tue, 26 Jan 2010 12:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bt2q67OaBOZj for ; Tue, 26 Jan 2010 12:48:21 -0800 (PST) Received: from mail-yw0-f196.google.com (mail-yw0-f196.google.com [209.85.211.196]) by core3.amsl.com (Postfix) with ESMTP id 2ADF828C0EF for ; Tue, 26 Jan 2010 12:48:21 -0800 (PST) Received: by ywh34 with SMTP id 34so3227547ywh.31 for ; Tue, 26 Jan 2010 12:48:29 -0800 (PST) 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=tWaKqmVa+VlnISvVRwU5cYFmJYqw9EZBHszpyi9xZzY=; b=Cg8QYW2nmEzaAiUKi95DtaeaffUyT0DpiXxUb9OZmsy7iAHhDhlHcsuiNhiGHWNVzK /y1xV7QYCG4BU3MsJxmyLlVW9cUwU8jD0Lx4nY8+h3sWfwh6aAuh5v8jc7mDZb/fq3ho 2U/ur5d8rSMcGEGARzL+Bdbccbl9Bt7NJBH84= 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=l8tRKmGOOfF1f9BYMvBw8RtcbRrztg4p++GeFsMc64CkfB/j+BbAa55Ig7rF62AVJa mCrQFPZiB/amH+T7VqGlTDEQi5dNCkgUKYxuLKGUTl1IGAchyx1poiCVlyl0i5RWnHuy aSffiUvLS6flj1nj2W6HKg+nnev4vXBhvTmMo= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.150.32.19 with SMTP id f19mr11305087ybf.206.1264538903680; Tue, 26 Jan 2010 12:48:23 -0800 (PST) In-Reply-To: <201001261527.24439.richard.alimi@yale.edu> References: <201001221658.24381.richard.alimi@yale.edu> <8b2769931001261138u43e6222ifa38d3cda3a258e6@mail.gmail.com> <201001261527.24439.richard.alimi@yale.edu> Date: Tue, 26 Jan 2010 15:48:23 -0500 X-Google-Sender-Auth: 8e8a6a0c7a18fc5b Message-ID: <8b2769931001261248n293d1300q5da866d87f6f905e@mail.gmail.com> From: "David A. Bryan" To: Richard Alimi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: decade@ietf.org Subject: Re: [decade] Updated DECADE Charter 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, 26 Jan 2010 20:48:22 -0000 Thanks for getting back so quickly. I think the alternate text sections you suggest below clarify things nicely. Comments (mostly just me agreeing with you ;) ) inline below: On Tue, Jan 26, 2010 at 3:27 PM, Richard Alimi wro= te: > Hi David, > > First of all, thank you very much for taking the time to read the new pro= posed > charter and provide feedback. =A0Responses inline below: > >> Overall, while much better, there is still a bit of lack of clarity >> about what is being developed and what is definitely out of scope from >> a protocol perspective. I think the text is good that says we will try >> to re-use something (NFS, WebDav, etc.), for example, in para 4 it >> says that the WG will design a protocol that "leverage existing IETF >> protocols where possible, in particular for storing retrieving and >> managing data". However, I think folks could be confused when they >> then go on to read the third point for out of scope items is >> developing a new protocol to deliver content. >> >> My understanding is that there may be new work on a protocol to >> specify policies, and provide control messages and signaling around >> the transfers (possibly again reusing/extending or incoprorating some >> existing protocols), but that we would definitely reuse something for >> the actual transport, hence the third bullet in the out of scope >> items. > > Your understanding of the intent is correct. > > The intended meaning of the last "out of scope" item was to underline the= fact > that we don't want to design another NFS or WebDAV for transferring data,= but > instead re-use them. =A0Perhaps it could be clarified as: > > =A0"Developing a new protocol for data transport between P2P applications= and > =A0in-network storage." > > Do you think this clarifies it enough? I think that is much better. The clarification that the data transport itself won't be reinvented is really the key point (and something I mentioned in the BoF a couple times, so glad to see it here.) Interestingly, I noticed another very minor nit as I re-read that section in the original. The first bullet in the out of scope items is missing something. It says "Copyright protected or illegal content For example...". Maybe that should be "Copyright protected or illegal content management. For example..."? >> Similarly, the last sentence in para 3 could be read to imply >> we can't reuse HTTP, NFS, etc., when I *believe* the intent is to note >> that if they are reused, they may need to be extended or used as a >> part of a solution. > > I see the ambiguity here. Perhaps that sentence can be made more explicit= by > saying: > =A0Though there are existing data access protocols (e.g., HTTP, NFS, WebD= AV), > =A0they currently lack capabilities needed when applied in this context. > As part of DECADE, we aim to fill in the gaps and make certain protocols > usable in this context. Sounds pretty good. I would imagine we might extend, or might have a new protocol that makes use of (as part of it, either embedded or in concert with) an existing protocol to meet that goal. > >> I think we need a bit more clarity to distinguish >> between where we may reuse or may develop new (access control, >> resource control, etc.), and where we are definitely using existing >> (actual transport, from my recollection) and make that a bit more >> crisp for a newcomer to this group. > > In regards to identifying where we may need to extend the underlying prot= ocol, > we currently we have this text: > > =A0 =A0If the underlying protocol does not support certain data managemen= t > =A0 =A0operations, DECADE may seek to define such extensions and present = them to > =A0 =A0the respective working groups or create an Individual Submission i= f no > =A0 =A0active working group exists. > > We are operating under the assumption that the underlying protocol will > already support read/write (i.e., data transport), and may also have some > operations for managing whatever data is currently stored. However, there= may > be certain resource management operations that are not currently present.= This > is why we felt it necessary to call out that we may need to extend the se= t of > operations in the underlying protocol, and provide an avenue for doing th= at. > > [As a side note, re-reading the existing text, I believe that "data > management" should be changed to "resource management" since there may ex= ist a > need to manage resources other than data (e.g., bandwidth, connections).] Definitely agree here and support that change. > To make this distinction more clear, perhaps we can say something like: > > =A0 =A0... The underlying protocol will be used wherever possible to supp= ort > =A0 =A0DECADE's required operations. It is assumed that the underlying pr= otocol > =A0 =A0already supports data transport for reading from and writing to in= -network > =A0 =A0storage. If the existing underlying protocol does not support cert= ain > =A0 =A0resource management operations, DECADE may seek to define such ext= ensions > =A0 =A0and present them to the respective working groups or create an Ind= ividual > =A0 =A0Submission if no active working group exists. ... I think this makes sense. Thanks! David >> The last two sentences in para 2, when read together, read very oddly: >> >> "For P2P applications, closed P2P caching systems limit effective >> utilization of in-network storage. P2P protocols may be entirely >> unsupported, and applications may be better-equipped to decide how >> in-network storage is used to meet their specific requirements (e.g., >> data placement, access control and resource control)." >> >> maybe this? >> >> "For P2P applications, closed P2P caching systems limit effective >> utilization of in-network storage. Some P2P protocols may be entirely >> unsupported by a particular caching system. Additionally, applications >> may be better-equipped to decide how in-network storage is used to >> meet their specific requirements (e.g., data placement, access control >> and resource control)." > > This makes sense. This can be incorporated in the next revision. > >> In paragraph 4, I think maybe we are missing a word in this sentence: >> >> "...(2) specify access control for storing and retrieving data >> suitable for a P2P environment ..." >> >> access control settings? values? > > "policies" may characterize this better. =A0This can be added. Yep. I couldn't think of the right word, but policies seems like the right choice to me. >> The last sentence in the fourth WG item is a bit unclear as well: >> >> "This group may also create a profile of necessary operations from an >> existing IETF protocol to reduce the complexity and software footprint >> of a compliant implementation." >> >> I think we should be clear about what we mean by compliant >> implementation here (i.e., compliant with the existing protocol or >> with DECADE). I think we mean a compliant DECADE implementation. > > Yes, we do mean a compliant DECADE implementation. This can be clarified. > >> As always, goals and milestones are always wild guesses. Spoken as >> someone who chairs another group that currently appears to have >> significantly expired milestones (now that I noticed, guess I better >> go fix that...oops), these seem really, really aggressive... >> >> Overall, I think this is getting much closer to ready. Great job, and >> looking forward to hearing comments from others. > > We are also looking forward to hearing comments from others as well :) > > -- > Richard Alimi > Department of Computer Science > Yale University > From richard.alimi@yale.edu Tue Jan 26 12:54:21 2010 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 7445B3A69C7 for ; Tue, 26 Jan 2010 12:54:21 -0800 (PST) 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 1HnAfBS7Vwqm for ; Tue, 26 Jan 2010 12:54:20 -0800 (PST) Received: from pantheon-po33.its.yale.edu (pantheon-po33.its.yale.edu [130.132.50.94]) by core3.amsl.com (Postfix) with ESMTP id AF9AF3A69BF for ; Tue, 26 Jan 2010 12:54:20 -0800 (PST) Received: from poweredge.velvetsea.net (adsl-69-183-234-134.adsl.snet.net [69.183.234.134] (may be forged)) (authenticated bits=0) by pantheon-po33.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id o0QKsT4m021978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 26 Jan 2010 15:54:29 -0500 Received: from p4p-7.localnet (p4p-7.cs.yale.edu [128.36.233.97]) by poweredge.velvetsea.net (Postfix) with ESMTPSA id 2ECF542401D; Tue, 26 Jan 2010 15:54:29 -0500 (EST) From: Richard Alimi To: "David A. Bryan" Date: Tue, 26 Jan 2010 15:54:27 -0500 User-Agent: KMail/1.12.4 (Linux/2.6.31-gentoo-r6; KDE/4.3.4; x86_64; ; ) References: <201001221658.24381.richard.alimi@yale.edu> <201001261527.24439.richard.alimi@yale.edu> <8b2769931001261248n293d1300q5da866d87f6f905e@mail.gmail.com> In-Reply-To: <8b2769931001261248n293d1300q5da866d87f6f905e@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201001261554.27976.richard.alimi@yale.edu> X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) Cc: decade@ietf.org Subject: Re: [decade] Updated DECADE Charter 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, 26 Jan 2010 20:54:21 -0000 On Tuesday 26 January 2010 3:48:23 pm David A. Bryan wrote: > Thanks for getting back so quickly. I think the alternate text > sections you suggest below clarify things nicely. Comments (mostly > just me agreeing with you ;) ) Great - thanks again, David. I've made a note of these changes and they'll be incorporated in the next pass of the document. It would be great to also get some comments from others, which would also be included. -- Richard Alimi Department of Computer Science Yale University From borje.ohlman@ericsson.com Wed Jan 27 01:02:41 2010 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 7AFBD3A6A20 for ; Wed, 27 Jan 2010 01:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] 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 exDzjHzaGPEZ for ; Wed, 27 Jan 2010 01:02:40 -0800 (PST) Received: from mailgw-virt-test.ericsson.se (mailgw-virt-test.ericsson.se [193.180.251.35]) by core3.amsl.com (Postfix) with ESMTP id 494D13A691A for ; Wed, 27 Jan 2010 01:02:38 -0800 (PST) X-AuditID: c1b4fb23-b7b3fae00000170d-64-4b60013abbb4 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw-virt-test.ericsson.se (Symantec Brightmail Gateway) with SMTP id D8.9C.05901.A31006B4; Wed, 27 Jan 2010 10:02:51 +0100 (CET) Received: from esealmw103.eemea.ericsson.se ([153.88.200.66]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 10:01:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jan 2010 10:01:19 +0100 Message-ID: <314AF86E2FDEB9458540143E41EED8CE0E2F85@esealmw103.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] Updated DECADE Charter Thread-Index: Acqbrg1B3lo93o9+Qq6cDFpjchRZkwDe1P8s References: <201001221658.24381.richard.alimi@yale.edu> From: =?iso-8859-1?Q?B=F6rje_Ohlman?= To: "Richard Alimi" , X-OriginalArrivalTime: 27 Jan 2010 09:01:20.0711 (UTC) FILETIME=[4B2EAD70:01CA9F2F] X-Brightmail-Tracker: AAAAAA== Subject: Re: [decade] Updated DECADE Charter 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, 27 Jan 2010 09:02:41 -0000 Hi All, I think this charter starts to look quite good. Though here are two issues I would like to see added to it. 1) How DECADE deals with copies in the in-network storage I think it would be good to make clear if the network part of DECADE can = benefit when multiple users/application stores the same information = object (e.g. file). Is it then possible for DECADE to store only one = copy of the information object or is it required to store multiple = copies of the same object? 2) Should DECADE support mobility of terminals/users/applications? A lot of today's terminals are mobile, e.g. laptops and smartphones. = When they move should their in-network storage move with them or should = access to their storage be made by tunneling back to some type of "home = storage"? I think these two issues are important as depending on what is required = it will have a strong influence on what protocols and mechanism will be = deemed appropriate. As I also think people have quite varying = assumptions, depending on background, on these things I think it is = important to spell it out in the charter. Finally a formulation I find confusing. In =A75 it states: "The Working Group (WG) will design and specify a standard protocol for = P2P=20 applications to utilize in-network storage." Then in the last bullet of out-of-scope issues it states: "Developing a new protocol to deliver content between P2P application = and in-network storage." A new proposal for this statement is: "Developing a new protocol for data transport between P2P applications = and in-network storage." I think both these alternatives can easily be seen as contradicting the = initial statement. As I understand it, what is out of scope are protocols between two p2p = applications, e.g. BitTorrent like protocols, as well as protocols = between two instances of in-network storage, e.g. for cache migration. = But protocols for data transport between a p2p application and an = in-network storage is very much *in* scope. I think it would be good to = state this explicitly, so there is no risk for misunderstanding. Best regards, B=F6rje Ohlman Ericsson Research PS. For those of you that don't know me, I'm a colleague to Martin Johnsson = who presented the Networking of Information work from the 4WARD project = at the last IETF meeting. -----Ursprungligt meddelande----- Fr=E5n: decade-bounces@ietf.org genom Richard Alimi Skickat: fr 2010-01-22 22:58 Till: decade@ietf.org =C4mne: [decade] Updated DECADE Charter =20 Hi All, We have been working on a new charter with a refined scope and = incorporating=20 past discussion on the mailing list. It would be wonderful to hear = comments=20 on the new proposed charter. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D DECoupled Application Data Enroute Description of Working Group: Peer-to-Peer (P2P) applications, including both P2P streaming and P2P = file- sharing applications, make up a large fraction of traffic in the = Internet=20 today. One way to reduce access network and/or cross-domain bandwidth = usage by=20 P2P applications is to introduce storage capabilities in the networks. =20 Allowing P2P applications to store and retrieve data from inside = networks can=20 reduce traffic on the last-mile uplink, as well as backbone and transit = links. Existing P2P caches often implement the specific P2P application = protocols to=20 operate transparently or act as super peers to provide in-network = storage.=20 However, this approach poses challenges to both P2P cache vendors and = P2P=20 application developers. For P2P cache vendors, the challenge is to = support a=20 variety of exisiting and evolving protocols. For P2P applications, = closed P2P=20 caching systems limit effective utilization of in-network storage. Some = P2P=20 protocols may be entirely unsupported, and applications may be = better-equipped=20 to decide how in-network storage is used to meet their specific = requirements=20 (e.g., data placement, access control and resource control). Both of these challenges can be effectively addressed by using an open,=20 standard protocol to access in-network storage. P2P applications can = store and=20 retrieve content in the in-network storage, as well as control resources = (e.g., bandwidth, connections) consumed by peers in a P2P application. = As a=20 simple example, a peer can choose to store content in the in-network = storage,=20 and direct other peers to retrieve from that location, reducing = last-mile link=20 usage. Though there are existing data access protocols (e.g., HTTP, = NFS,=20 WebDAV), they lack capabilities needed when applied in this context. The Working Group (WG) will design and specify a standard protocol for = P2P=20 applications to utilize in-network storage. The protocol will include=20 operations for a P2P application to (1) store, retrieve, and manage = data, (2)=20 specify access control for storing and retrieving data suitable for a = P2P=20 environment with peers across multiple administrative and security = domains,=20 and (3) indicate resource control policies for storing and retrieving = data. =20 The WG will leverage existing IETF protocols where possible, in = particular for=20 storing, retrieving, and managing data. This WG will focus mainly on the protocol between the in-network storage = and=20 P2P applications. The protocol will be focused on P2P applications, = though it=20 may also be used in other types of applications. The WG will focus on the following work items: - A "problem statement" document. This document provides a description = of the problem and common terminology. - A requirements document. This document lists the requirements for the in-network storage service (e.g., supported operations) and the = protocol to support it.=20 - A survey document. This document will survey existing related = mechanisms and protocols (e.g., HTTP, NFS, and WebDAV), and evaluate their=20 applicability and effectiveness. - A signaling protocol for storing, retrieving, and managing data as = well as specifying both access control and resource control policies in the in-network storage pertaining to that data. Data storage, retrieval, = and management may be provided by an existing IETF protocol. If the = underlying protocol does not support certain data management operations, DECADE = may seek to define such extensions and present them to the respective = working groups or create an Individual Submission if no active working group = exists.=20 This group may also create a profile of necessary operations from an existing IETF protocol to reduce the complexity and software footprint = of a compliant implementation. The WG will not limit itself to a single underlying protocol since = different underlying protocols may have varying implementation costs and = performance tradeoffs. To keep interoperability manageable, a small number of = specific, targeted, underlying protocols will be used. NFS and WebDAV are = initial targets and others may be incorporated with WG consensus. - An informational document describing the integration of DECADE with = existing P2P applications (e.g., integration with BitTorrent). The following issues are not considered in the current scope of the WG: - Copyright protected or illegal content For example, one possibility is that that an in-network storage system = may have system-wide ingress and egress filters to implement policies = related to copyrighted and illegal content. This is outside the scope of this = working group. - Locating the "best" in-network storage location from which to retrieve content if there are more than one location can provide the same = content. - Developing a new protocol to deliver content between P2P application = and in-network storage. Goals and Milestones: May 2010 Working Group Last Call for problem statement=20 Aug 2010 Submit problem statement to IESG as Informational=20 Aug 2010 Working Group Last Call for requirements document=20 Feb 2011 Submit requirements document to IESG as Informational=20 May 2011 Working Group Last Call for survey document=20 Aug 2011 Working Group Last Call for in-network storage access protocol Aug 2011 Submit survey document to IESG as Informational Nov 2011 Submit in-network storage access protocol to IESG as Proposed Standard =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thanks! --=20 Richard Alimi Department of Computer Science Yale University _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade From christian.1.schmidt@nsn.com Wed Jan 27 01:20:28 2010 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 354AF3A68EB for ; Wed, 27 Jan 2010 01:20:28 -0800 (PST) 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 XoaQUNefK44S for ; Wed, 27 Jan 2010 01:20:26 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 5F9AE3A68E3 for ; Wed, 27 Jan 2010 01:20:25 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o0R9KWhl024618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 Jan 2010 10:20:33 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o0R9KUoV005707; Wed, 27 Jan 2010 10:20:32 +0100 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 10:20:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jan 2010 10:20:28 +0100 Message-ID: In-Reply-To: <8b2769931001261248n293d1300q5da866d87f6f905e@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] Updated DECADE Charter Thread-Index: AcqeyPEYaukZDYE7TOeRR9+3LMnhdgAZwidA References: <201001221658.24381.richard.alimi@yale.edu><8b2769931001261138u43e6222ifa38d3cda3a258e6@mail.gmail.com><201001261527.24439.richard.alimi@yale.edu> <8b2769931001261248n293d1300q5da866d87f6f905e@mail.gmail.com> From: "Schmidt, Christian 1. (NSN - DE/Munich)" To: "ext David A. Bryan" , "Richard Alimi" X-OriginalArrivalTime: 27 Jan 2010 09:20:31.0931 (UTC) FILETIME=[F95CE8B0:01CA9F31] Cc: decade@ietf.org Subject: Re: [decade] Updated DECADE Charter 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, 27 Jan 2010 09:20:28 -0000 Hi Bryan, >Interestingly, I noticed another very minor nit as I re-read that >section in the original. The first bullet in the out of scope items is >missing something. It says "Copyright protected or illegal content For >example...". Maybe that should be "Copyright protected or illegal >content management. For example..."? What do you mean with illegal content management? Transcoding? Content = manipulation? Perhaps, this could be added as additional point, but this was not meant = here. With illegal content we mean e.g. certain kinds of pornography. So my proposal would be: "Copyright protected or illegal content and illicit content = manipulation." What do you think about? BR Christian=20 =20 -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf = Of ext David A. Bryan Sent: Tuesday, January 26, 2010 9:48 PM To: Richard Alimi Cc: decade@ietf.org Subject: Re: [decade] Updated DECADE Charter Thanks for getting back so quickly. I think the alternate text sections you suggest below clarify things nicely. Comments (mostly just me agreeing with you ;) ) inline below: On Tue, Jan 26, 2010 at 3:27 PM, Richard Alimi = wrote: > Hi David, > > First of all, thank you very much for taking the time to read the new = proposed > charter and provide feedback. =A0Responses inline below: > >> Overall, while much better, there is still a bit of lack of clarity >> about what is being developed and what is definitely out of scope = from >> a protocol perspective. I think the text is good that says we will = try >> to re-use something (NFS, WebDav, etc.), for example, in para 4 it >> says that the WG will design a protocol that "leverage existing IETF >> protocols where possible, in particular for storing retrieving and >> managing data". However, I think folks could be confused when they >> then go on to read the third point for out of scope items is >> developing a new protocol to deliver content. >> >> My understanding is that there may be new work on a protocol to >> specify policies, and provide control messages and signaling around >> the transfers (possibly again reusing/extending or incoprorating some >> existing protocols), but that we would definitely reuse something for >> the actual transport, hence the third bullet in the out of scope >> items. > > Your understanding of the intent is correct. > > The intended meaning of the last "out of scope" item was to underline = the fact > that we don't want to design another NFS or WebDAV for transferring = data, but > instead re-use them. =A0Perhaps it could be clarified as: > > =A0"Developing a new protocol for data transport between P2P = applications and > =A0in-network storage." > > Do you think this clarifies it enough? I think that is much better. The clarification that the data transport itself won't be reinvented is really the key point (and something I mentioned in the BoF a couple times, so glad to see it here.) Interestingly, I noticed another very minor nit as I re-read that section in the original. The first bullet in the out of scope items is missing something. It says "Copyright protected or illegal content For example...". Maybe that should be "Copyright protected or illegal content management. For example..."? >> Similarly, the last sentence in para 3 could be read to imply >> we can't reuse HTTP, NFS, etc., when I *believe* the intent is to = note >> that if they are reused, they may need to be extended or used as a >> part of a solution. > > I see the ambiguity here. Perhaps that sentence can be made more = explicit by > saying: > =A0Though there are existing data access protocols (e.g., HTTP, NFS, = WebDAV), > =A0they currently lack capabilities needed when applied in this = context. > As part of DECADE, we aim to fill in the gaps and make certain = protocols > usable in this context. Sounds pretty good. I would imagine we might extend, or might have a new protocol that makes use of (as part of it, either embedded or in concert with) an existing protocol to meet that goal. > >> I think we need a bit more clarity to distinguish >> between where we may reuse or may develop new (access control, >> resource control, etc.), and where we are definitely using existing >> (actual transport, from my recollection) and make that a bit more >> crisp for a newcomer to this group. > > In regards to identifying where we may need to extend the underlying = protocol, > we currently we have this text: > > =A0 =A0If the underlying protocol does not support certain data = management > =A0 =A0operations, DECADE may seek to define such extensions and = present them to > =A0 =A0the respective working groups or create an Individual = Submission if no > =A0 =A0active working group exists. > > We are operating under the assumption that the underlying protocol = will > already support read/write (i.e., data transport), and may also have = some > operations for managing whatever data is currently stored. However, = there may > be certain resource management operations that are not currently = present. This > is why we felt it necessary to call out that we may need to extend the = set of > operations in the underlying protocol, and provide an avenue for doing = that. > > [As a side note, re-reading the existing text, I believe that "data > management" should be changed to "resource management" since there may = exist a > need to manage resources other than data (e.g., bandwidth, = connections).] Definitely agree here and support that change. > To make this distinction more clear, perhaps we can say something = like: > > =A0 =A0... The underlying protocol will be used wherever possible to = support > =A0 =A0DECADE's required operations. It is assumed that the underlying = protocol > =A0 =A0already supports data transport for reading from and writing to = in-network > =A0 =A0storage. If the existing underlying protocol does not support = certain > =A0 =A0resource management operations, DECADE may seek to define such = extensions > =A0 =A0and present them to the respective working groups or create an = Individual > =A0 =A0Submission if no active working group exists. ... I think this makes sense. Thanks! David >> The last two sentences in para 2, when read together, read very = oddly: >> >> "For P2P applications, closed P2P caching systems limit effective >> utilization of in-network storage. P2P protocols may be entirely >> unsupported, and applications may be better-equipped to decide how >> in-network storage is used to meet their specific requirements (e.g., >> data placement, access control and resource control)." >> >> maybe this? >> >> "For P2P applications, closed P2P caching systems limit effective >> utilization of in-network storage. Some P2P protocols may be entirely >> unsupported by a particular caching system. Additionally, = applications >> may be better-equipped to decide how in-network storage is used to >> meet their specific requirements (e.g., data placement, access = control >> and resource control)." > > This makes sense. This can be incorporated in the next revision. > >> In paragraph 4, I think maybe we are missing a word in this sentence: >> >> "...(2) specify access control for storing and retrieving data >> suitable for a P2P environment ..." >> >> access control settings? values? > > "policies" may characterize this better. =A0This can be added. Yep. I couldn't think of the right word, but policies seems like the right choice to me. >> The last sentence in the fourth WG item is a bit unclear as well: >> >> "This group may also create a profile of necessary operations from an >> existing IETF protocol to reduce the complexity and software = footprint >> of a compliant implementation." >> >> I think we should be clear about what we mean by compliant >> implementation here (i.e., compliant with the existing protocol or >> with DECADE). I think we mean a compliant DECADE implementation. > > Yes, we do mean a compliant DECADE implementation. This can be = clarified. > >> As always, goals and milestones are always wild guesses. Spoken as >> someone who chairs another group that currently appears to have >> significantly expired milestones (now that I noticed, guess I better >> go fix that...oops), these seem really, really aggressive... >> >> Overall, I think this is getting much closer to ready. Great job, and >> looking forward to hearing comments from others. > > We are also looking forward to hearing comments from others as well :) > > -- > Richard Alimi > Department of Computer Science > Yale University > _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade From richard.alimi@yale.edu Wed Jan 27 01:44:45 2010 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 30F5E3A6A39 for ; Wed, 27 Jan 2010 01:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 gwEknN+qgj7N for ; Wed, 27 Jan 2010 01:44:44 -0800 (PST) Received: from pantheon-po34.its.yale.edu (pantheon-po34.its.yale.edu [130.132.50.80]) by core3.amsl.com (Postfix) with ESMTP id EF7833A68FD for ; Wed, 27 Jan 2010 01:44:43 -0800 (PST) Received: from poweredge.velvetsea.net (adsl-69-183-235-25.adsl.snet.net [69.183.235.25] (may be forged)) (authenticated bits=0) by pantheon-po34.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id o0R9imjh030513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Jan 2010 04:44:48 -0500 Received: from laptop.localnet (unknown [192.168.1.74]) by poweredge.velvetsea.net (Postfix) with ESMTPSA id 6B90B42401D; Wed, 27 Jan 2010 04:44:48 -0500 (EST) From: Richard Alimi To: =?iso-8859-1?q?B=F6rje_Ohlman?= Date: Wed, 27 Jan 2010 04:44:47 -0500 User-Agent: KMail/1.12.4 (Linux/2.6.31-gentoo-r6; KDE/4.3.4; x86_64; ; ) References: <201001221658.24381.richard.alimi@yale.edu> <314AF86E2FDEB9458540143E41EED8CE0E2F85@esealmw103.eemea.ericsson.se> In-Reply-To: <314AF86E2FDEB9458540143E41EED8CE0E2F85@esealmw103.eemea.ericsson.se> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201001270444.47316.richard.alimi@yale.edu> X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) Cc: decade@ietf.org Subject: Re: [decade] Updated DECADE Charter 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, 27 Jan 2010 09:44:45 -0000 Hi B=F6rje, Thanks for taking the time to provide feedback. See below: On Wednesday 27 January 2010 4:01:19 am B=F6rje Ohlman wrote: > Hi All, >=20 > I think this charter starts to look quite good. > Though here are two issues I would like to see added to it. >=20 > 1) How DECADE deals with copies in the in-network storage > I think it would be good to make clear if the network part of DECADE can > benefit when multiple users/application stores the same information obje= ct > (e.g. file). Is it then possible for DECADE to store only one copy of the > information object or is it required to store multiple copies of the same > object? While this is an optimization that could be worthwhile, my feeling is that = it=20 does not matter with respect to the protocol between the application and th= e=20 storage. If the storage system were to have such a feature, it may be an=20 implementation detail. Are you envisioning a case where this would surface= in=20 the protocol? In our Bar BoF at IETF75, I remember Rich Woundy had mentioned a case=20 (pertaining to remote DVR, if I recall correctly) where a provider was lega= lly=20 required to *not* merge multiple copies of the same data. Rich - do I reca= ll=20 this correctly? > 2) Should DECADE support mobility of terminals/users/applications? > A lot of today's terminals are mobile, e.g. laptops and smartphones. When > they move should their in-network storage move with them or should access > to their storage be made by tunneling back to some type of "home storage= "? >=20 > I think these two issues are important as depending on what is required it > will have a strong influence on what protocols and mechanism will be > deemed appropriate. As I also think people have quite varying assumption= s, > depending on background, on these things I think it is important to spell > it out in the charter. I think this is a good discussion to have and it would be great to get=20 opinions from others. My personal feeling is to leave automatic data migrat= ion=20 out of scope, since it may make the system quite complicated. In particular= ,=20 one of the things we explicitly mentioned as out-of-scope was finding the=20 "best" in-network storage element. I think that what you mention here for=20 mobility is somewhat related to this. However, this does mean we would need to be careful to not all of a sudden= =20 redirect a mobile user to a storage element without their data. One simple possibility for mobile applications to use DECADE is to rely on= =20 end-user applications to direct when, where, and what data is migrated. Thi= s=20 could be done with some very simple interfaces (see the "remote-get" interf= ace=20 we mentioned in the strawman proposal at IETF76). This can be simpler for = the=20 storage provider, and the end-user may be the person best-qualified to make= =20 these decisions. > Finally a formulation I find confusing. > In =A75 it states: > "The Working Group (WG) will design and specify a standard protocol for P= 2P > applications to utilize in-network storage." > Then in the last bullet of out-of-scope issues it states: > "Developing a new protocol to deliver content between P2P application and > in-network storage." > A new proposal for this statement is: > "Developing a new protocol for data transport between P2P applications and > in-network storage." > I think both these alternatives can easily be seen as contradicting the > initial statement. > As I understand it, what is out of scope are protocols > between two p2p applications, e.g. BitTorrent like protocols, Yes - this is out-of-scope. > as well as > protocols between two instances of in-network storage, e.g. for cache > migration. The protocol between two in-network storage instances is not currently out-= of- scope. One case where such a protocol can be useful in P2P is when both th= e=20 uploading and downloading user have in-network storage. See section 5.3.1 o= f=20 the current draft of the problem statement for an example: http://tools.ietf.org/html/draft-song-decade-problem-statement-00 In the eventual specification, the actual data transport between two in- network storages may be done by the underlying protocol, but we may also ne= ed=20 to pass access control / resource control between them as well (which would= be=20 in scope for DECADE). > But protocols for data transport between a p2p application and > an in-network storage is very much *in* scope. The idea is that we'd like to be able to use existing storage access protoc= ols=20 where possible. The candidates that we mention in the charter currently ar= e=20 NFS and WebDAV. However, in DECADE, we need to pass some additional=20 information between the user and in-network storage (e.g., resource control= =20 and access control). Do you have suggestions for an alternate wording here? Thanks! =2D-=20 Richard Alimi Department of Computer Science Yale University From enrico.marocco@telecomitalia.it Wed Jan 27 02:01:41 2010 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 EC99C3A6910 for ; Wed, 27 Jan 2010 02:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8hjWbHTg2zv for ; Wed, 27 Jan 2010 02:01:40 -0800 (PST) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by core3.amsl.com (Postfix) with ESMTP id 25D353A6A14 for ; Wed, 27 Jan 2010 02:01:40 -0800 (PST) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 27 Jan 2010 11:01:50 +0100 Received: from [163.162.173.7] (163.162.173.7) by GRFHUB701BA020.griffon.local (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 27 Jan 2010 11:01:50 +0100 Message-ID: <4B600F16.1000706@telecomitalia.it> Date: Wed, 27 Jan 2010 11:01:58 +0100 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) MIME-Version: 1.0 To: Richard Alimi References: <201001221658.24381.richard.alimi@yale.edu> In-Reply-To: <201001221658.24381.richard.alimi@yale.edu> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080807010303030608070105" Cc: "decade@ietf.org" Subject: Re: [decade] Updated DECADE Charter 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, 27 Jan 2010 10:01:42 -0000 --------------ms080807010303030608070105 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks for putting this together! In general I like text, but one thing I think we should do very carefully is to precisely list what we are sure is missing from existing protocols -- fine grained access and resource control, right? -- as, at the end of the day, that will be the reason why the IESG may decide to charter a new WG. To this extent, I'd prefer to be more explicit, at the risk of being redundant, e.g. in the last sentence of paragraph 3: Though there are existing data access protocols (e.g., HTTP, NFS, WebDAV), they lack capabilities needed when applied in this context. What about replacing it with something along this line? Though there are existing data access protocols (e.g., HTTP, NFS, WebDAV), they lack capabilities for fine-grained access and resource control that are essential for today's advanced P2P algorithms. Enrico Richard Alimi wrote: > Hi All, > > We have been working on a new charter with a refined scope and incorporating > past discussion on the mailing list. It would be wonderful to hear comments > on the new proposed charter. > > ======================================================================== > > DECoupled Application Data Enroute > > Description of Working Group: > > Peer-to-Peer (P2P) applications, including both P2P streaming and P2P file- > sharing applications, make up a large fraction of traffic in the Internet > today. One way to reduce access network and/or cross-domain bandwidth usage by > P2P applications is to introduce storage capabilities in the networks. > Allowing P2P applications to store and retrieve data from inside networks can > reduce traffic on the last-mile uplink, as well as backbone and transit links. > > Existing P2P caches often implement the specific P2P application protocols to > operate transparently or act as super peers to provide in-network storage. > However, this approach poses challenges to both P2P cache vendors and P2P > application developers. For P2P cache vendors, the challenge is to support a > variety of exisiting and evolving protocols. For P2P applications, closed P2P > caching systems limit effective utilization of in-network storage. Some P2P > protocols may be entirely unsupported, and applications may be better-equipped > to decide how in-network storage is used to meet their specific requirements > (e.g., data placement, access control and resource control). > > Both of these challenges can be effectively addressed by using an open, > standard protocol to access in-network storage. P2P applications can store and > retrieve content in the in-network storage, as well as control resources > (e.g., bandwidth, connections) consumed by peers in a P2P application. As a > simple example, a peer can choose to store content in the in-network storage, > and direct other peers to retrieve from that location, reducing last-mile link > usage. Though there are existing data access protocols (e.g., HTTP, NFS, > WebDAV), they lack capabilities needed when applied in this context. > > The Working Group (WG) will design and specify a standard protocol for P2P > applications to utilize in-network storage. The protocol will include > operations for a P2P application to (1) store, retrieve, and manage data, (2) > specify access control for storing and retrieving data suitable for a P2P > environment with peers across multiple administrative and security domains, > and (3) indicate resource control policies for storing and retrieving data. > The WG will leverage existing IETF protocols where possible, in particular for > storing, retrieving, and managing data. > > This WG will focus mainly on the protocol between the in-network storage and > P2P applications. The protocol will be focused on P2P applications, though it > may also be used in other types of applications. > > The WG will focus on the following work items: > > - A "problem statement" document. This document provides a description of the > problem and common terminology. > > - A requirements document. This document lists the requirements for the > in-network storage service (e.g., supported operations) and the protocol to > support it. > > - A survey document. This document will survey existing related mechanisms > and protocols (e.g., HTTP, NFS, and WebDAV), and evaluate their > applicability and effectiveness. > > - A signaling protocol for storing, retrieving, and managing data as well as > specifying both access control and resource control policies in the > in-network storage pertaining to that data. Data storage, retrieval, and > management may be provided by an existing IETF protocol. If the underlying > protocol does not support certain data management operations, DECADE may > seek to define such extensions and present them to the respective working > groups or create an Individual Submission if no active working group exists. > This group may also create a profile of necessary operations from an > existing IETF protocol to reduce the complexity and software footprint of a > compliant implementation. > > The WG will not limit itself to a single underlying protocol since different > underlying protocols may have varying implementation costs and performance > tradeoffs. To keep interoperability manageable, a small number of specific, > targeted, underlying protocols will be used. NFS and WebDAV are initial > targets and others may be incorporated with WG consensus. > > - An informational document describing the integration of DECADE with existing > P2P applications (e.g., integration with BitTorrent). > > The following issues are not considered in the current scope of the WG: > > - Copyright protected or illegal content > For example, one possibility is that that an in-network storage system may > have system-wide ingress and egress filters to implement policies related to > copyrighted and illegal content. This is outside the scope of this working > group. > > - Locating the "best" in-network storage location from which to retrieve > content if there are more than one location can provide the same content. > > - Developing a new protocol to deliver content between P2P application and > in-network storage. > > Goals and Milestones: > > May 2010 Working Group Last Call for problem statement > Aug 2010 Submit problem statement to IESG as Informational > Aug 2010 Working Group Last Call for requirements document > Feb 2011 Submit requirements document to IESG as Informational > May 2011 Working Group Last Call for survey document > Aug 2011 Working Group Last Call for in-network storage access protocol > Aug 2011 Submit survey document to IESG as Informational > Nov 2011 Submit in-network storage access protocol to IESG as Proposed > Standard > > ======================================================================== > > Thanks! --------------ms080807010303030608070105 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPADCC BEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1 MTAyNzIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnf rOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs +Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVch rKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ +dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5gJ925rXXOL3OVekA6hXVJsLjf aLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUCAwEAAaOB/zCB/DASBgNV HRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4 QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwzLTIwNDgt MTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAihiBo dHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOBgQA8o9oC YzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aTi55u uUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBVcwggQ/oAMCAQICEFpR0fRWUeGQw2sT05Fc7iMwDQYJKoZI hvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0EgLSBHMjAeFw0wOTEwMTQwMDAwMDBaFw0xMDEwMTQyMzU5NTlaMIIBIDEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBi eSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEz MDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRcw FQYDVQQDFA5FbnJpY28gTWFyb2NjbzEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29A dGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANzEqZU+ /oQJ6BQFa8ThesCWP8niY551IGWhB0e/kr8VKQU4/umEa2pBM5xhm6IhEX+a4DVvM/xg/1bG z4q8cMgGZ02cjSvIfFGJvhg90zAhpAVqj7+P5Dc8UrHf5riD8nhmgfP7bfxlOCRe6/Hf/fXN TC7iFELNIu1VipP9YacNayCSbTGEum+qbhZUMHsrfoof3uS1QCWD/waapIDZA2Rirx50cW8l HjMGGRT2ZQdCsk77T3jbybDWpFgaB+/EmFQvxUaI1XaSTvhBCbXc8fjvLUy4rW0fRyFPkzDx wMcfxasMrxUopXFozZVFHU90nqOnjOTVbNxWuRK6jtfygKUCAwEAAaOBzDCByTAJBgNVHRME AjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQG CCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly9JbmRDMURpZ2l0YWxJRC1jcmwu dmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDANBgkqhkiG9w0BAQUFAAOCAQEAUFzN Pck16/XpsGsBqzF60efNewjYZz1Hg6nbJ89nS0bQ8oR1WNWQa1vqBiAXnmhBj/JbKir5+02B 3VLMHrWagiyBDl5jkhds6OSqrFSxftnI/FDuI2venlnLMoUKMiDKl9nYt6TSxPfsmVMEwC/l PePeKf7xIW2c3rFPnkDU3myc7giECjVvr5247GknfKcI5GLh82qjfW3CaiLOB+3h9Ho34aJl Cp3uWie4W9F9ekA7oFmrfA1tLHfH+Z/ZzCvFATQWjeJ1PE/IlP0DtYO2ZcVMdVO5UMwYxoVN E2uL25M+9ufDIUYVNSeq0M1Ro0FmSlhYlsa2nHcT2c+c+LQyFTCCBVcwggQ/oAMCAQICEFpR 0fRWUeGQw2sT05Fc7iMwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjAeFw0wOTEwMTQwMDAwMDBa Fw0xMDEwMTQyMzU5NTlaMIIBIDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0 c2NhcGUgRnVsbCBTZXJ2aWNlMRcwFQYDVQQDFA5FbnJpY28gTWFyb2NjbzEuMCwGCSqGSIb3 DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANzEqZU+/oQJ6BQFa8ThesCWP8niY551IGWhB0e/kr8VKQU4/umE a2pBM5xhm6IhEX+a4DVvM/xg/1bGz4q8cMgGZ02cjSvIfFGJvhg90zAhpAVqj7+P5Dc8UrHf 5riD8nhmgfP7bfxlOCRe6/Hf/fXNTC7iFELNIu1VipP9YacNayCSbTGEum+qbhZUMHsrfoof 3uS1QCWD/waapIDZA2Rirx50cW8lHjMGGRT2ZQdCsk77T3jbybDWpFgaB+/EmFQvxUaI1XaS TvhBCbXc8fjvLUy4rW0fRyFPkzDxwMcfxasMrxUopXFozZVFHU90nqOnjOTVbNxWuRK6jtfy gKUCAwEAAaOBzDCByTAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAo BggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6 Ly9JbmRDMURpZ2l0YWxJRC1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDAN BgkqhkiG9w0BAQUFAAOCAQEAUFzNPck16/XpsGsBqzF60efNewjYZz1Hg6nbJ89nS0bQ8oR1 WNWQa1vqBiAXnmhBj/JbKir5+02B3VLMHrWagiyBDl5jkhds6OSqrFSxftnI/FDuI2venlnL MoUKMiDKl9nYt6TSxPfsmVMEwC/lPePeKf7xIW2c3rFPnkDU3myc7giECjVvr5247GknfKcI 5GLh82qjfW3CaiLOB+3h9Ho34aJlCp3uWie4W9F9ekA7oFmrfA1tLHfH+Z/ZzCvFATQWjeJ1 PE/IlP0DtYO2ZcVMdVO5UMwYxoVNE2uL25M+9ufDIUYVNSeq0M1Ro0FmSlhYlsa2nHcT2c+c +LQyFTGCBOwwggToAgEBMIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEFpR0fRWUeGQw2sT05Fc7iMwCQYFKw4DAhoF AKCCAs4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAwMTI3 MTAwMTU4WjAjBgkqhkiG9w0BCQQxFgQUlORnCHAKM+OBWIyYr3VMtC3Kx0wwXwYJKoZIhvcN AQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIIBAwYJKwYBBAGCNxAEMYH1MIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzICEFpR0fRWUeGQw2sT05Fc7iMwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TEL MAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2ln biBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVk MTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt IEcyAhBaUdH0VlHhkMNrE9ORXO4jMA0GCSqGSIb3DQEBAQUABIIBAKm4iEviLNio8550PFeo oA5mzJCYSSvACrYiJ4iXqQvLa/ffOMIp2Agz/wok1KBEhby2HB+jx/ZZ3z3CwSdUP6Kpdn3f DBvtX8X0uF21fl/xCAgSPZbLVuyNWUerya/wIRQCt0AEl+nqeN8xbB4lfL5VbgkW7ZcpGMRa AO4DvPFwcHIug89iSzRdDZCfJ8PS3s2NxtVUSVU7ZnFBODydg3gZOB6zo8hMrcaEWZme+aqa F8YGtFhSM/vDmmSopHEaam4reobp1+vE4wjraIiWKBSufPWicFTfWh+cyAPk71Q6ur/iO0Lg 6Oo2p15Bs1OOo7l4SWHT24BYr44ovWxjw7oAAAAAAAA= --------------ms080807010303030608070105-- From ove.strandberg@nsn.com Wed Jan 27 02:13:17 2010 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 D42133A6A32 for ; Wed, 27 Jan 2010 02:13:17 -0800 (PST) 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 CjRJ6OaBG-Us for ; Wed, 27 Jan 2010 02:13:16 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id D86C33A68BC for ; Wed, 27 Jan 2010 02:13:15 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o0RADRON032318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 Jan 2010 11:13:27 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o0RADRVa023071; Wed, 27 Jan 2010 11:13:27 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 11:13:27 +0100 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: Wed, 27 Jan 2010 12:13:26 +0200 Message-ID: In-Reply-To: <4B600F16.1000706@telecomitalia.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] Updated DECADE Charter Thread-Index: AcqfN8VsiuqE2r8KQ0qgOs229v+PcAAANeEg References: <201001221658.24381.richard.alimi@yale.edu> <4B600F16.1000706@telecomitalia.it> From: "Strandberg, Ove (NSN - FI/Espoo)" To: "ext Enrico Marocco" , "Richard Alimi" X-OriginalArrivalTime: 27 Jan 2010 10:13:27.0509 (UTC) FILETIME=[5E27A850:01CA9F39] Cc: decade@ietf.org Subject: Re: [decade] Updated DECADE Charter 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, 27 Jan 2010 10:13:18 -0000 Hi all, At the pre-BOF in Stockholm also other applications than P2P was discussed. I probably missed some of the discussion in Hiroshima, but I would appriciate shifting focus from P2P intpo more generic use of network storage, eg. We should not get into too P2P specific solution. The statement: "The protocol will be focused on P2P applications, though it may also be used in other types of applications." Could be reworked: "The protocol will be focused on P2P applications, though it should be generic to allow usage in other types of applications also." Br, +Ove Ps. I also have background in Network of Information in 4WARD project. Ds.=20 >-----Original Message----- >From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org]=20 >On Behalf Of ext Enrico Marocco >Sent: 27 January, 2010 12:02 >To: Richard Alimi >Cc: decade@ietf.org >Subject: Re: [decade] Updated DECADE Charter > >Thanks for putting this together! > >In general I like text, but one thing I think we should do=20 >very carefully is to precisely list what we are sure is=20 >missing from existing protocols -- fine grained access and=20 >resource control, right? -- as, at the end of the day, that=20 >will be the reason why the IESG may decide to charter a new=20 >WG. To this extent, I'd prefer to be more explicit, at the=20 >risk of being redundant, e.g. in the last sentence of paragraph 3: > > Though there are existing data access protocols (e.g., HTTP, NFS, > WebDAV), they lack capabilities needed when applied in this context. > >What about replacing it with something along this line? > > Though there are existing data access protocols (e.g., HTTP, NFS, > WebDAV), they lack capabilities for fine-grained access and resource > control that are essential for today's advanced P2P algorithms. > >Enrico > >Richard Alimi wrote: >> Hi All, >>=20 >> We have been working on a new charter with a refined scope and=20 >> incorporating past discussion on the mailing list. It would be=20 >> wonderful to hear comments on the new proposed charter. >>=20 >>=20 >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> =3D=3D >>=20 >> DECoupled Application Data Enroute >>=20 >> Description of Working Group: >>=20 >> Peer-to-Peer (P2P) applications, including both P2P=20 >streaming and P2P=20 >> file- sharing applications, make up a large fraction of=20 >traffic in the=20 >> Internet today. One way to reduce access network and/or cross-domain=20 >> bandwidth usage by P2P applications is to introduce storage=20 >capabilities in the networks. >> Allowing P2P applications to store and retrieve data from inside=20 >> networks can reduce traffic on the last-mile uplink, as well=20 >as backbone and transit links. >>=20 >> Existing P2P caches often implement the specific P2P application=20 >> protocols to operate transparently or act as super peers to=20 >provide in-network storage. >> However, this approach poses challenges to both P2P cache=20 >vendors and=20 >> P2P application developers. For P2P cache vendors, the=20 >challenge is to=20 >> support a variety of exisiting and evolving protocols. For P2P=20 >> applications, closed P2P caching systems limit effective utilization=20 >> of in-network storage. Some P2P protocols may be entirely=20 >unsupported,=20 >> and applications may be better-equipped to decide how in-network=20 >> storage is used to meet their specific requirements (e.g.,=20 >data placement, access control and resource control). >>=20 >> Both of these challenges can be effectively addressed by using an=20 >> open, standard protocol to access in-network storage. P2P=20 >applications=20 >> can store and retrieve content in the in-network storage, as well as=20 >> control resources (e.g., bandwidth, connections) consumed by=20 >peers in=20 >> a P2P application. As a simple example, a peer can choose to store=20 >> content in the in-network storage, and direct other peers to=20 >retrieve=20 >> from that location, reducing last-mile link usage. Though there are=20 >> existing data access protocols (e.g., HTTP, NFS, WebDAV),=20 >they lack capabilities needed when applied in this context. >>=20 >> The Working Group (WG) will design and specify a standard=20 >protocol for=20 >> P2P applications to utilize in-network storage. The protocol will=20 >> include operations for a P2P application to (1) store, retrieve, and=20 >> manage data, (2) specify access control for storing and retrieving=20 >> data suitable for a P2P environment with peers across multiple=20 >> administrative and security domains, and (3) indicate=20 >resource control policies for storing and retrieving data. >> The WG will leverage existing IETF protocols where possible, in=20 >> particular for storing, retrieving, and managing data. >>=20 >> This WG will focus mainly on the protocol between the in-network=20 >> storage and P2P applications. The protocol will be focused on P2P=20 >> applications, though it may also be used in other types of=20 >applications. >>=20 >> The WG will focus on the following work items: >>=20 >> - A "problem statement" document. This document provides a=20 >description of the >> problem and common terminology. >>=20 >> - A requirements document. This document lists the=20 >requirements for the >> in-network storage service (e.g., supported operations)=20 >and the protocol to >> support it.=20 >>=20 >> - A survey document. This document will survey existing=20 >related mechanisms >> and protocols (e.g., HTTP, NFS, and WebDAV), and evaluate their=20 >> applicability and effectiveness. >>=20 >> - A signaling protocol for storing, retrieving, and managing=20 >data as well as >> specifying both access control and resource control policies in the >> in-network storage pertaining to that data. Data storage,=20 >retrieval, and >> management may be provided by an existing IETF protocol.=20 >If the underlying >> protocol does not support certain data management=20 >operations, DECADE may >> seek to define such extensions and present them to the=20 >respective working >> groups or create an Individual Submission if no active=20 >working group exists.=20 >> This group may also create a profile of necessary=20 >operations from an >> existing IETF protocol to reduce the complexity and=20 >software footprint of a >> compliant implementation. >>=20 >> The WG will not limit itself to a single underlying=20 >protocol since different >> underlying protocols may have varying implementation costs=20 >and performance >> tradeoffs. To keep interoperability manageable, a small=20 >number of specific, >> targeted, underlying protocols will be used. NFS and=20 >WebDAV are initial >> targets and others may be incorporated with WG consensus. >>=20 >> - An informational document describing the integration of=20 >DECADE with existing >> P2P applications (e.g., integration with BitTorrent). >>=20 >> The following issues are not considered in the current scope=20 >of the WG: >>=20 >> - Copyright protected or illegal content >> For example, one possibility is that that an in-network=20 >storage system may >> have system-wide ingress and egress filters to implement=20 >policies related to >> copyrighted and illegal content. This is outside the=20 >scope of this working >> group. >>=20 >> - Locating the "best" in-network storage location from which=20 >to retrieve >> content if there are more than one location can provide=20 >the same content. >>=20 >> - Developing a new protocol to deliver content between P2P=20 >application and >> in-network storage. >>=20 >> Goals and Milestones: >>=20 >> May 2010 Working Group Last Call for problem statement Aug 2010 =20 >> Submit problem statement to IESG as Informational Aug 2010 Working=20 >> Group Last Call for requirements document Feb 2011 Submit=20 >> requirements document to IESG as Informational May 2011 =20 >Working Group=20 >> Last Call for survey document Aug 2011 Working Group Last Call for=20 >> in-network storage access protocol Aug 2011 Submit survey=20 >document to=20 >> IESG as Informational Nov 2011 Submit in-network storage access=20 >> protocol to IESG as Proposed >> Standard >>=20 >>=20 >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> =3D=3D >>=20 >> Thanks! > From lars.eggert@nokia.com Wed Jan 27 03:42:00 2010 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 EA7AE3A6A56 for ; Wed, 27 Jan 2010 03:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.605 X-Spam-Level: X-Spam-Status: No, score=-6.605 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 bA2t2+8Z-O8j for ; Wed, 27 Jan 2010 03:42:00 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id BC8FB3A67F5 for ; Wed, 27 Jan 2010 03:41:59 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0RBftJR006919; Wed, 27 Jan 2010 13:42:11 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 13:41:52 +0200 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 13:41:52 +0200 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0RBfpDB017213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jan 2010 13:41:51 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-1-669974457; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4B600F16.1000706@telecomitalia.it> Date: Wed, 27 Jan 2010 13:41:39 +0200 Message-Id: <9FEC9AF8-6E4F-45C7-B108-DD70A3190CD2@nokia.com> References: <201001221658.24381.richard.alimi@yale.edu> <4B600F16.1000706@telecomitalia.it> To: Enrico Marocco X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Wed, 27 Jan 2010 13:41:45 +0200 (EET) X-OriginalArrivalTime: 27 Jan 2010 11:41:52.0802 (UTC) FILETIME=[B85B2020:01CA9F45] X-Nokia-AV: Clean Cc: "decade@ietf.org" Subject: Re: [decade] Updated DECADE Charter 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, 27 Jan 2010 11:42:01 -0000 --Apple-Mail-1-669974457 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-1-27, at 12:01, Enrico Marocco wrote: > What about replacing it with something along this line? >=20 > Though there are existing data access protocols (e.g., HTTP, NFS, > WebDAV), they lack capabilities for fine-grained access and resource > control that are essential for today's advanced P2P algorithms. NFSv4 supports ACLs, so if you want to make the case that it lacks = fine-grained access control I'd personally need some further convincing. As for resource control, I think you have identified one of NFSv4's = current shortcomings for this use case. To charter some new protocol = development here, I would personally need to see an argument that that = was somehow less development effort than adding resource control = mechanisms to NFSv4 (e.g., through the hints mechanism.) Lars= --Apple-Mail-1-669974457 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDEyNzExNDEzOVowIwYJKoZIhvcNAQkEMRYEFB6vW9YMJPWrtP66jkD4vo6fcXFXMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQDdZgEfVJS0ZHdno1xbkN2FGq2ayDctSMWSDsMBAHnD9k786WHDy4Xe54T6SL4pFEog5N62 37m1ezA0PHAXQriYIugXgfCwjuz54H6C9R09l0e5LJkJSA3ITJ7Ty/nGDVwOzJQQyFAAXnwEDjIn MAqFLNROOR7/8gKrWnL52w9r3+cS5qzJq9fzBoM7RjuLee9w/kp0IAVs4e7g8c3LJMC2MJ3v+6Kb 3dynMN6t6GUn751clc4Iz668EtoK3UdKaAbZeUkjD27d6AU1VEBuTYr0AGnC6GYC61KqLg31HVvO GH2DTfgdQ+P1E813awXiR5CgNbz5ttr3XyFPcJTAUqtMAAAAAAAA --Apple-Mail-1-669974457-- From enrico.marocco@telecomitalia.it Wed Jan 27 04:15:18 2010 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 666F23A6A1E for ; Wed, 27 Jan 2010 04:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hN6Sg79gRyrY for ; Wed, 27 Jan 2010 04:15:17 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id 0EB303A689D for ; Wed, 27 Jan 2010 04:15:17 -0800 (PST) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 27 Jan 2010 13:15:21 +0100 Received: from [163.162.173.7] (163.162.173.7) by GRFHUB701BA020.griffon.local (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 27 Jan 2010 13:15:20 +0100 Message-ID: <4B602E5B.5090809@telecomitalia.it> Date: Wed, 27 Jan 2010 13:15:23 +0100 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) MIME-Version: 1.0 To: Lars Eggert References: <201001221658.24381.richard.alimi@yale.edu> <4B600F16.1000706@telecomitalia.it> <9FEC9AF8-6E4F-45C7-B108-DD70A3190CD2@nokia.com> In-Reply-To: <9FEC9AF8-6E4F-45C7-B108-DD70A3190CD2@nokia.com> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080209070701080103090306" Cc: "decade@ietf.org" Subject: Re: [decade] Updated DECADE Charter 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, 27 Jan 2010 12:15:18 -0000 --------------ms080209070701080103090306 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Lars Eggert wrote: >> What about replacing it with something along this line? >> >> Though there are existing data access protocols (e.g., HTTP, NFS, >> WebDAV), they lack capabilities for fine-grained access and >> resource control that are essential for today's advanced P2P >> algorithms. > > NFSv4 supports ACLs, so if you want to make the case that it lacks > fine-grained access control I'd personally need some further > convincing. I was actually thinking of access control at a chunk level, assuming such a fine granularity would be actually useful to P2P applications. However, I agree that what's certainly missing is the ability to allocate and control resources like bandwidth and number of connections. > As for resource control, I think you have identified one of NFSv4's > current shortcomings for this use case. To charter some new protocol > development here, I would personally need to see an argument that > that was somehow less development effort than adding resource control > mechanisms to NFSv4 (e.g., through the hints mechanism.) Makes sense to me, even if I suspect we disagree on the timing of such a discussion -- I'd be perfectly comfortable with letting the WG-to-be evaluate and decide whether to do resource control in a new protocol, or to define it as an extension for an existing one (as stated in #4 of the work items list), but I guess the same doesn't hold for you. -- Ciao, Enrico --------------ms080209070701080103090306 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPADCC BEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1 MTAyNzIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnf rOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs +Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVch rKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ +dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5gJ925rXXOL3OVekA6hXVJsLjf aLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUCAwEAAaOB/zCB/DASBgNV HRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4 QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwzLTIwNDgt MTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAihiBo dHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOBgQA8o9oC YzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aTi55u uUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBVcwggQ/oAMCAQICEFpR0fRWUeGQw2sT05Fc7iMwDQYJKoZI hvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0EgLSBHMjAeFw0wOTEwMTQwMDAwMDBaFw0xMDEwMTQyMzU5NTlaMIIBIDEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBi eSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEz MDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRcw FQYDVQQDFA5FbnJpY28gTWFyb2NjbzEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29A dGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANzEqZU+ /oQJ6BQFa8ThesCWP8niY551IGWhB0e/kr8VKQU4/umEa2pBM5xhm6IhEX+a4DVvM/xg/1bG z4q8cMgGZ02cjSvIfFGJvhg90zAhpAVqj7+P5Dc8UrHf5riD8nhmgfP7bfxlOCRe6/Hf/fXN TC7iFELNIu1VipP9YacNayCSbTGEum+qbhZUMHsrfoof3uS1QCWD/waapIDZA2Rirx50cW8l HjMGGRT2ZQdCsk77T3jbybDWpFgaB+/EmFQvxUaI1XaSTvhBCbXc8fjvLUy4rW0fRyFPkzDx wMcfxasMrxUopXFozZVFHU90nqOnjOTVbNxWuRK6jtfygKUCAwEAAaOBzDCByTAJBgNVHRME AjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQG CCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly9JbmRDMURpZ2l0YWxJRC1jcmwu dmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDANBgkqhkiG9w0BAQUFAAOCAQEAUFzN Pck16/XpsGsBqzF60efNewjYZz1Hg6nbJ89nS0bQ8oR1WNWQa1vqBiAXnmhBj/JbKir5+02B 3VLMHrWagiyBDl5jkhds6OSqrFSxftnI/FDuI2venlnLMoUKMiDKl9nYt6TSxPfsmVMEwC/l PePeKf7xIW2c3rFPnkDU3myc7giECjVvr5247GknfKcI5GLh82qjfW3CaiLOB+3h9Ho34aJl Cp3uWie4W9F9ekA7oFmrfA1tLHfH+Z/ZzCvFATQWjeJ1PE/IlP0DtYO2ZcVMdVO5UMwYxoVN E2uL25M+9ufDIUYVNSeq0M1Ro0FmSlhYlsa2nHcT2c+c+LQyFTCCBVcwggQ/oAMCAQICEFpR 0fRWUeGQw2sT05Fc7iMwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjAeFw0wOTEwMTQwMDAwMDBa Fw0xMDEwMTQyMzU5NTlaMIIBIDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0 c2NhcGUgRnVsbCBTZXJ2aWNlMRcwFQYDVQQDFA5FbnJpY28gTWFyb2NjbzEuMCwGCSqGSIb3 DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANzEqZU+/oQJ6BQFa8ThesCWP8niY551IGWhB0e/kr8VKQU4/umE a2pBM5xhm6IhEX+a4DVvM/xg/1bGz4q8cMgGZ02cjSvIfFGJvhg90zAhpAVqj7+P5Dc8UrHf 5riD8nhmgfP7bfxlOCRe6/Hf/fXNTC7iFELNIu1VipP9YacNayCSbTGEum+qbhZUMHsrfoof 3uS1QCWD/waapIDZA2Rirx50cW8lHjMGGRT2ZQdCsk77T3jbybDWpFgaB+/EmFQvxUaI1XaS TvhBCbXc8fjvLUy4rW0fRyFPkzDxwMcfxasMrxUopXFozZVFHU90nqOnjOTVbNxWuRK6jtfy gKUCAwEAAaOBzDCByTAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAo BggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6 Ly9JbmRDMURpZ2l0YWxJRC1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDAN BgkqhkiG9w0BAQUFAAOCAQEAUFzNPck16/XpsGsBqzF60efNewjYZz1Hg6nbJ89nS0bQ8oR1 WNWQa1vqBiAXnmhBj/JbKir5+02B3VLMHrWagiyBDl5jkhds6OSqrFSxftnI/FDuI2venlnL MoUKMiDKl9nYt6TSxPfsmVMEwC/lPePeKf7xIW2c3rFPnkDU3myc7giECjVvr5247GknfKcI 5GLh82qjfW3CaiLOB+3h9Ho34aJlCp3uWie4W9F9ekA7oFmrfA1tLHfH+Z/ZzCvFATQWjeJ1 PE/IlP0DtYO2ZcVMdVO5UMwYxoVNE2uL25M+9ufDIUYVNSeq0M1Ro0FmSlhYlsa2nHcT2c+c +LQyFTGCBOwwggToAgEBMIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzICEFpR0fRWUeGQw2sT05Fc7iMwCQYFKw4DAhoF AKCCAs4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAwMTI3 MTIxNTIzWjAjBgkqhkiG9w0BCQQxFgQUAbBvgsCrjndE4O9uHZp47Wjqwt0wXwYJKoZIhvcN AQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqG SIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIIBAwYJKwYBBAGCNxAEMYH1MIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzICEFpR0fRWUeGQw2sT05Fc7iMwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TEL MAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2ln biBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVk MTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAt IEcyAhBaUdH0VlHhkMNrE9ORXO4jMA0GCSqGSIb3DQEBAQUABIIBAFgCDLggnKgPIeQLa3fn sTEuNCjWJmoujeKE8NnDxFJGaRA3Dc5SRbarosLdPbxNMjEdccUCj2CyM6BE3TSk784orQAO MboQ8PuW+u5f6Qm5iQ0rdMzbALh8V5hkIbrCPve7ZsPG+ITkIcJgiw12p4rEi+AdsnkGOJUe 80CYGcYNQZ3TgerhrTzg5VYHh91hc0SJeSzBsEAvX0sGSvltfnDkkbZI3yaHeeQTfx/y3s08 ZpM/EDFSw2wPOetI3j1XGM5Jp3JA2ofejPI/7ig/2Ns+vNvQLg9d+7RqLOO0kZDauBnQZwYv tcRp9mcISD1K/A7KbLPRLQgK4tIIcv5FaTUAAAAAAAA= --------------ms080209070701080103090306-- From richard.alimi@yale.edu Wed Jan 27 06:19:15 2010 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 C70753A6976 for ; Wed, 27 Jan 2010 06:19:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.449 X-Spam-Level: X-Spam-Status: No, score=-4.449 tagged_above=-999 required=5 tests=[AWL=2.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 C98CIV77SbXU for ; Wed, 27 Jan 2010 06:19:14 -0800 (PST) Received: from pantheon-po29.its.yale.edu (pantheon-po29.its.yale.edu [130.132.50.124]) by core3.amsl.com (Postfix) with ESMTP id A18143A6921 for ; Wed, 27 Jan 2010 06:19:14 -0800 (PST) Received: from poweredge.velvetsea.net (adsl-69-183-235-25.adsl.snet.net [69.183.235.25] (may be forged)) (authenticated bits=0) by pantheon-po29.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id o0REJKnv003081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Jan 2010 09:19:23 -0500 Received: from laptop.localnet (unknown [192.168.1.74]) by poweredge.velvetsea.net (Postfix) with ESMTPSA id 30F9842401D; Wed, 27 Jan 2010 09:19:20 -0500 (EST) From: Richard Alimi To: Lars Eggert Date: Wed, 27 Jan 2010 09:19:18 -0500 User-Agent: KMail/1.12.4 (Linux/2.6.31-gentoo-r6; KDE/4.3.4; x86_64; ; ) References: <201001221658.24381.richard.alimi@yale.edu> <4B600F16.1000706@telecomitalia.it> <9FEC9AF8-6E4F-45C7-B108-DD70A3190CD2@nokia.com> In-Reply-To: <9FEC9AF8-6E4F-45C7-B108-DD70A3190CD2@nokia.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201001270919.18847.richard.alimi@yale.edu> X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) Cc: "decade@ietf.org" Subject: Re: [decade] Updated DECADE Charter 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, 27 Jan 2010 14:19:16 -0000 Hi Lars, On Wednesday 27 January 2010 6:41:39 am Lars Eggert wrote: > Hi, > > On 2010-1-27, at 12:01, Enrico Marocco wrote: > > What about replacing it with something along this line? > > > > Though there are existing data access protocols (e.g., HTTP, NFS, > > WebDAV), they lack capabilities for fine-grained access and resource > > control that are essential for today's advanced P2P algorithms. > > NFSv4 supports ACLs, so if you want to make the case that it lacks > fine-grained access control I'd personally need some further convincing. It was my understanding that NFS requires the server to have an account for each user that can be granted permissions. Or, are there other models that are supported that you could point me to? One of the things that we included in the charter was the following: ... specify access control for storing and retrieving data suitable for a P2P environment with peers across multiple administrative and security domains ... In the P2P context, a client can have a particular policy (e.g., to implement incentives) indicating which data (and how fast) to send to particular peers. Others should be prevented from fetching those same blocks from the client's in-network storage. Both the set of blocks being distributed and the peers to which they are being sent can change at a small timescale. Would NFS's ACLs be suited for this? My concern was that the client would have to do the following: (1) Register a new user with the NFS server for each new peer to which data is being sent. (2) For each block (or set of blocks) sent to the peer, add the peer to the ACLs for those blocks. (3) Remove the peer from the ACLs and delete the user when the peer is disconnected. This sounds like a lot of overhead for both the client and the server. One possibility for avoiding the overhead is to have a scheme using access tokens. Clients can hand out tokens (possibly with an expiration time) without involvement from the server. The server just needs to verify the token when data is requested. -- Richard Alimi Department of Computer Science Yale University From melodysong@huawei.com Wed Jan 27 08:34:21 2010 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 7F22C3A6972 for ; Wed, 27 Jan 2010 08:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.544 X-Spam-Level: *** X-Spam-Status: No, score=3.544 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1, SARE_RECV_IP_219128=1.666] 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 QrKKZImudutZ for ; Wed, 27 Jan 2010 08:34:20 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 415EC3A6940 for ; Wed, 27 Jan 2010 08:34:18 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWW00LP4ZDAPE@szxga01-in.huawei.com> for decade@ietf.org; Thu, 28 Jan 2010 00:34:22 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWW00ISTZDAGQ@szxga01-in.huawei.com> for decade@ietf.org; Thu, 28 Jan 2010 00:34:22 +0800 (CST) Received: from 975DEF9223E44C7 ([219.135.157.220]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KWW000GDZDAOC@szxml02-in.huawei.com>; Thu, 28 Jan 2010 00:34:22 +0800 (CST) Date: Thu, 28 Jan 2010 00:34:18 +0800 From: Haibin Song To: Richard Alimi , Lars Eggert Message-id: <201001280034178120262@huawei.com> MIME-version: 1.0 X-Mailer: Foxmail 6, 15, 201, 22 [cn] Content-type: multipart/alternative; boundary="Boundary_(ID_ELtB2QsdmLn+gB12WYiyqA)" References: <201001221658.24381.richard.alimi@yale.edu> <4B600F16.1000706@telecomitalia.it> <9FEC9AF8-6E4F-45C7-B108-DD70A3190CD2@nokia.com> <201001270919.18847.richard.alimi@yale.edu> Cc: "decade@ietf.org" Subject: Re: [decade] Updated DECADE Charter 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, 27 Jan 2010 16:34:21 -0000 This is a multi-part message in MIME format. --Boundary_(ID_ELtB2QsdmLn+gB12WYiyqA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT I agree. And another reason is that when we consider various implementations, we feel should not limit the underlying protocol to NFS, but we must consider it as one of the main underlying protocol for data transport and content structure. 2010-01-28 Haibin Song On 2010-01-27 22:19:42 Richard Alimi wrote: > Hi Lars, On Wednesday 27 January 2010 6:41:39 am Lars Eggert wrote: > Hi, > > On 2010-1-27, at 12:01, Enrico Marocco wrote: > > What about replacing it with something along this line? > > > > Though there are existing data access protocols (e.g., HTTP, NFS, > > WebDAV), they lack capabilities for fine-grained access and resource > > control that are essential for today's advanced P2P algorithms. > > NFSv4 supports ACLs, so if you want to make the case that it lacks > fine-grained access control I'd personally need some further convincing. It was my understanding that NFS requires the server to have an account for each user that can be granted permissions. Or, are there other models that are supported that you could point me to? One of the things that we included in the charter was the following: ... specify access control for storing and retrieving data suitable for a P2P environment with peers across multiple administrative and security domains ... In the P2P context, a client can have a particular policy (e.g., to implement incentives) indicating which data (and how fast) to send to particular peers. Others should be prevented from fetching those same blocks from the client's in-network storage. Both the set of blocks being distributed and the peers to which they are being sent can change at a small timescale. Would NFS's ACLs be suited for this? My concern was that the client would have to do the following: (1) Register a new user with the NFS server for each new peer to which data is being sent. (2) For each block (or set of blocks) sent to the peer, add the peer to the ACLs for those blocks. (3) Remove the peer from the ACLs and delete the user when the peer is disconnected. This sounds like a lot of overhead for both the client and the server. One possibility for avoiding the overhead is to have a scheme using access tokens. Clients can hand out tokens (possibly with an expiration time) without involvement from the server. The server just needs to verify the token when data is requested. -- Richard Alimi Department of Computer Science Yale University _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade --Boundary_(ID_ELtB2QsdmLn+gB12WYiyqA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjMyNDMiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPkBmb250LWZhY2Ugew0KCWZvbnQt ZmFtaWx5OiDLzszlOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IFZlcmRhbmE7DQp9 DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogQMvOzOU7DQp9DQpAcGFnZSBTZWN0aW9uMSB7 c2l6ZTogNTk1LjNwdCA4NDEuOXB0OyBtYXJnaW46IDcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBw dDsgbGF5b3V0LWdyaWQ6IDE1LjZwdDsgfQ0KUC5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTog aW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsg Rk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpM SS5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6 IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9t YW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpESVYuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJ Rlk6IGludGVyLWlkZW9ncmFwaDsgRk9OVC1TSVpFOiAxMC41cHQ7IE1BUkdJTjogMGNtIDBjbSAw cHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlmeQ0K fQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0N ClNQQU4uTXNvSHlwZXJsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRl cmxpbmUNCn0NCkE6dmlzaXRlZCB7DQoJQ09MT1I6IHB1cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1 bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rRm9sbG93ZWQgew0KCUNPTE9SOiBwdXJwbGU7 IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLkVtYWlsU3R5bGUxNyB7DQoJRk9O VC1XRUlHSFQ6IG5vcm1hbDsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtU1RZTEU6IG5vcm1hbDsg Rk9OVC1GQU1JTFk6IFZlcmRhbmE7IFRFWFQtREVDT1JBVElPTjogbm9uZTsgbXNvLXN0eWxlLXR5 cGU6IHBlcnNvbmFsLWNvbXBvc2UNCn0NCkRJVi5TZWN0aW9uMSB7DQoJcGFnZTogU2VjdGlvbjEN Cn0NClVOS05PV04gew0KCUZPTlQtU0laRTogMTBwdA0KfQ0KQkxPQ0tRVU9URSB7DQoJTUFSR0lO LVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1MRUZUOiAyZW0NCn0NCk9MIHsN CglNQVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KVUwgew0KCU1BUkdJTi1U T1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4DQp9DQo8L1NUWUxFPg0KPC9IRUFEPg0KPEJPRFkg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgTUFSR0lOOiAxMHB4OyBGT05ULUZBTUlMWTogdmVyZGFu YSI+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMDgwIHNpemU9Mj5JIGFncmVl LiBBbmQgYW5vdGhlciByZWFzb24gaXMgdGhhdCANCndoZW4gd2UgY29uc2lkZXIgdmFyaW91cyBp bXBsZW1lbnRhdGlvbnMsIHdlIGZlZWwgc2hvdWxkIG5vdCBsaW1pdCB0aGUgDQp1bmRlcmx5aW5n IHByb3RvY29sIHRvIE5GUywgYnV0IHdlIG11c3QgY29uc2lkZXIgaXQgYXMgb25lIG9mIHRoZSBt YWluIA0KdW5kZXJseWluZyBwcm90b2NvbCBmb3IgZGF0YSB0cmFuc3BvcnQgYW5kIGNvbnRlbnQg c3RydWN0dXJlLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMw MDAwODAgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5h IGNvbG9yPSMwMDAwODAgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT1WZXJkYW5hIGNvbG9yPSNjMGMwYzAgc2l6ZT0yPjIwMTAtMDEtMjggPC9GT05UPjwvRElWPjxG T05UIA0KZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwODAgc2l6ZT0yPg0KPEhSIHN0eWxlPSJXSURU SDogMTAwcHgiIGFsaWduPWxlZnQgY29sb3I9I2I1YzRkZiBTSVpFPTE+DQo8L0ZPTlQ+DQo8RElW PjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jYzBjMGMwIHNpemU9Mj48U1BBTj5IYWliaW4gU29u ZzwvU1BBTj4gDQo8L0ZPTlQ+PC9ESVY+DQo8SFIgY29sb3I9I2I1YzRkZiBTSVpFPTE+DQoNCjxE SVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj5PbiZuYnNwOzIwMTAtMDEtMjcmbmJzcDsgMjI6 MTk6NDImbmJzcDsmbmJzcDsgDQpSaWNoYXJkIEFsaW1pJm5ic3A7IHdyb3RlOjwvRk9OVD4mbmJz cDsgPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6 ZT0yPiZndDsNCjxESVY+SGkmbmJzcDtMYXJzLDwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+T24m bmJzcDtXZWRuZXNkYXkmbmJzcDsyNyZuYnNwO0phbnVhcnkmbmJzcDsyMDEwJm5ic3A7Njo0MToz OSZuYnNwO2FtJm5ic3A7TGFycyZuYnNwO0VnZ2VydCZuYnNwO3dyb3RlOjwvRElWPg0KPERJVj4m Z3Q7Jm5ic3A7SGksPC9ESVY+DQo8RElWPiZndDsmbmJzcDs8L0RJVj4NCjxESVY+Jmd0OyZuYnNw O09uJm5ic3A7MjAxMC0xLTI3LCZuYnNwO2F0Jm5ic3A7MTI6MDEsJm5ic3A7RW5yaWNvJm5ic3A7 TWFyb2NjbyZuYnNwO3dyb3RlOjwvRElWPg0KPERJVj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwO1doYXQm bmJzcDthYm91dCZuYnNwO3JlcGxhY2luZyZuYnNwO2l0Jm5ic3A7d2l0aCZuYnNwO3NvbWV0aGlu ZyZuYnNwO2Fsb25nJm5ic3A7dGhpcyZuYnNwO2xpbmU/PC9ESVY+DQo8RElWPiZndDsmbmJzcDsm Z3Q7PC9ESVY+DQo8RElWPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7Jm5ic3A7VGhvdWdoJm5ic3A7dGhl cmUmbmJzcDthcmUmbmJzcDtleGlzdGluZyZuYnNwO2RhdGEmbmJzcDthY2Nlc3MmbmJzcDtwcm90 b2NvbHMmbmJzcDsoZS5nLiwmbmJzcDtIVFRQLCZuYnNwO05GUyw8L0RJVj4NCjxESVY+Jmd0OyZu YnNwOyZndDsmbmJzcDsmbmJzcDtXZWJEQVYpLCZuYnNwO3RoZXkmbmJzcDtsYWNrJm5ic3A7Y2Fw YWJpbGl0aWVzJm5ic3A7Zm9yJm5ic3A7ZmluZS1ncmFpbmVkJm5ic3A7YWNjZXNzJm5ic3A7YW5k Jm5ic3A7cmVzb3VyY2U8L0RJVj4NCjxESVY+Jmd0OyZuYnNwOyZndDsmbmJzcDsmbmJzcDtjb250 cm9sJm5ic3A7dGhhdCZuYnNwO2FyZSZuYnNwO2Vzc2VudGlhbCZuYnNwO2ZvciZuYnNwO3RvZGF5 J3MmbmJzcDthZHZhbmNlZCZuYnNwO1AyUCZuYnNwO2FsZ29yaXRobXMuPC9ESVY+DQo8RElWPiZn dDsmbmJzcDs8L0RJVj4NCjxESVY+Jmd0OyZuYnNwO05GU3Y0Jm5ic3A7c3VwcG9ydHMmbmJzcDtB Q0xzLCZuYnNwO3NvJm5ic3A7aWYmbmJzcDt5b3UmbmJzcDt3YW50Jm5ic3A7dG8mbmJzcDttYWtl Jm5ic3A7dGhlJm5ic3A7Y2FzZSZuYnNwO3RoYXQmbmJzcDtpdCZuYnNwO2xhY2tzPC9ESVY+DQo8 RElWPiZndDsmbmJzcDsmbmJzcDtmaW5lLWdyYWluZWQmbmJzcDthY2Nlc3MmbmJzcDtjb250cm9s Jm5ic3A7SSdkJm5ic3A7cGVyc29uYWxseSZuYnNwO25lZWQmbmJzcDtzb21lJm5ic3A7ZnVydGhl ciZuYnNwO2NvbnZpbmNpbmcuPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5JdCZuYnNwO3dhcyZu YnNwO215Jm5ic3A7dW5kZXJzdGFuZGluZyZuYnNwO3RoYXQmbmJzcDtORlMmbmJzcDtyZXF1aXJl cyZuYnNwO3RoZSZuYnNwO3NlcnZlciZuYnNwO3RvJm5ic3A7aGF2ZSZuYnNwO2FuJm5ic3A7YWNj b3VudCZuYnNwO2ZvciZuYnNwOzwvRElWPg0KPERJVj5lYWNoJm5ic3A7dXNlciZuYnNwO3RoYXQm bmJzcDtjYW4mbmJzcDtiZSZuYnNwO2dyYW50ZWQmbmJzcDtwZXJtaXNzaW9ucy4mbmJzcDsmbmJz cDtPciwmbmJzcDthcmUmbmJzcDt0aGVyZSZuYnNwO290aGVyJm5ic3A7bW9kZWxzJm5ic3A7dGhh dCZuYnNwOzwvRElWPg0KPERJVj5hcmUmbmJzcDtzdXBwb3J0ZWQmbmJzcDt0aGF0Jm5ic3A7eW91 Jm5ic3A7Y291bGQmbmJzcDtwb2ludCZuYnNwO21lJm5ic3A7dG8/PC9ESVY+DQo8RElWPjwvRElW Pg0KPERJVj5PbmUmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3RoaW5ncyZuYnNwO3RoYXQmbmJzcDt3 ZSZuYnNwO2luY2x1ZGVkJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtjaGFydGVyJm5ic3A7d2FzJm5i c3A7dGhlJm5ic3A7Zm9sbG93aW5nOjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+Jm5ic3A7Jm5i c3A7Li4uJm5ic3A7c3BlY2lmeSZuYnNwO2FjY2VzcyZuYnNwO2NvbnRyb2wmbmJzcDtmb3ImbmJz cDtzdG9yaW5nJm5ic3A7YW5kJm5ic3A7cmV0cmlldmluZyZuYnNwO2RhdGEmbmJzcDtzdWl0YWJs ZSZuYnNwO2ZvciZuYnNwO2E8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7UDJQJm5ic3A7ZW52aXJv bm1lbnQmbmJzcDt3aXRoJm5ic3A7cGVlcnMmbmJzcDthY3Jvc3MmbmJzcDttdWx0aXBsZSZuYnNw O2FkbWluaXN0cmF0aXZlJm5ic3A7YW5kJm5ic3A7c2VjdXJpdHk8L0RJVj4NCjxESVY+Jm5ic3A7 Jm5ic3A7ZG9tYWlucyZuYnNwOy4uLjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+SW4mbmJzcDt0 aGUmbmJzcDtQMlAmbmJzcDtjb250ZXh0LCZuYnNwO2EmbmJzcDtjbGllbnQmbmJzcDtjYW4mbmJz cDtoYXZlJm5ic3A7YSZuYnNwO3BhcnRpY3VsYXImbmJzcDtwb2xpY3kmbmJzcDsoZS5nLiwmbmJz cDt0byZuYnNwO2ltcGxlbWVudCZuYnNwOzwvRElWPg0KPERJVj5pbmNlbnRpdmVzKSZuYnNwO2lu ZGljYXRpbmcmbmJzcDt3aGljaCZuYnNwO2RhdGEmbmJzcDsoYW5kJm5ic3A7aG93Jm5ic3A7ZmFz dCkmbmJzcDt0byZuYnNwO3NlbmQmbmJzcDt0byZuYnNwO3BhcnRpY3VsYXImbmJzcDtwZWVycy4m bmJzcDs8L0RJVj4NCjxESVY+T3RoZXJzJm5ic3A7c2hvdWxkJm5ic3A7YmUmbmJzcDtwcmV2ZW50 ZWQmbmJzcDtmcm9tJm5ic3A7ZmV0Y2hpbmcmbmJzcDt0aG9zZSZuYnNwO3NhbWUmbmJzcDtibG9j a3MmbmJzcDtmcm9tJm5ic3A7dGhlJm5ic3A7Y2xpZW50J3MmbmJzcDs8L0RJVj4NCjxESVY+aW4t bmV0d29yayZuYnNwO3N0b3JhZ2UuJm5ic3A7Jm5ic3A7Qm90aCZuYnNwO3RoZSZuYnNwO3NldCZu YnNwO29mJm5ic3A7YmxvY2tzJm5ic3A7YmVpbmcmbmJzcDtkaXN0cmlidXRlZCZuYnNwO2FuZCZu YnNwO3RoZSZuYnNwO3BlZXJzJm5ic3A7dG8mbmJzcDs8L0RJVj4NCjxESVY+d2hpY2gmbmJzcDt0 aGV5Jm5ic3A7YXJlJm5ic3A7YmVpbmcmbmJzcDtzZW50Jm5ic3A7Y2FuJm5ic3A7Y2hhbmdlJm5i c3A7YXQmbmJzcDthJm5ic3A7c21hbGwmbmJzcDt0aW1lc2NhbGUuPC9ESVY+DQo8RElWPjwvRElW Pg0KPERJVj5Xb3VsZCZuYnNwO05GUydzJm5ic3A7QUNMcyZuYnNwO2JlJm5ic3A7c3VpdGVkJm5i c3A7Zm9yJm5ic3A7dGhpcz8mbmJzcDtNeSZuYnNwO2NvbmNlcm4mbmJzcDt3YXMmbmJzcDt0aGF0 Jm5ic3A7dGhlJm5ic3A7Y2xpZW50Jm5ic3A7d291bGQmbmJzcDtoYXZlJm5ic3A7PC9ESVY+DQo8 RElWPnRvJm5ic3A7ZG8mbmJzcDt0aGUmbmJzcDtmb2xsb3dpbmc6PC9ESVY+DQo8RElWPigxKSZu YnNwO1JlZ2lzdGVyJm5ic3A7YSZuYnNwO25ldyZuYnNwO3VzZXImbmJzcDt3aXRoJm5ic3A7dGhl Jm5ic3A7TkZTJm5ic3A7c2VydmVyJm5ic3A7Zm9yJm5ic3A7ZWFjaCZuYnNwO25ldyZuYnNwO3Bl ZXImbmJzcDt0byZuYnNwO3doaWNoJm5ic3A7ZGF0YSZuYnNwO2lzPC9ESVY+DQo8RElWPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO2JlaW5nJm5ic3A7c2VudC48L0RJVj4NCjxESVY+KDIpJm5ic3A7 Rm9yJm5ic3A7ZWFjaCZuYnNwO2Jsb2NrJm5ic3A7KG9yJm5ic3A7c2V0Jm5ic3A7b2YmbmJzcDti bG9ja3MpJm5ic3A7c2VudCZuYnNwO3RvJm5ic3A7dGhlJm5ic3A7cGVlciwmbmJzcDthZGQmbmJz cDt0aGUmbmJzcDtwZWVyJm5ic3A7dG8mbmJzcDt0aGU8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7QUNMcyZuYnNwO2ZvciZuYnNwO3Rob3NlJm5ic3A7YmxvY2tzLjwvRElWPg0K PERJVj4oMykmbmJzcDtSZW1vdmUmbmJzcDt0aGUmbmJzcDtwZWVyJm5ic3A7ZnJvbSZuYnNwO3Ro ZSZuYnNwO0FDTHMmbmJzcDthbmQmbmJzcDtkZWxldGUmbmJzcDt0aGUmbmJzcDt1c2VyJm5ic3A7 d2hlbiZuYnNwO3RoZSZuYnNwO3BlZXImbmJzcDtpczwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDtkaXNjb25uZWN0ZWQuPC9ESVY+DQo8RElWPlRoaXMmbmJzcDtzb3VuZHMmbmJz cDtsaWtlJm5ic3A7YSZuYnNwO2xvdCZuYnNwO29mJm5ic3A7b3ZlcmhlYWQmbmJzcDtmb3ImbmJz cDtib3RoJm5ic3A7dGhlJm5ic3A7Y2xpZW50Jm5ic3A7YW5kJm5ic3A7dGhlJm5ic3A7c2VydmVy LjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+T25lJm5ic3A7cG9zc2liaWxpdHkmbmJzcDtmb3Im bmJzcDthdm9pZGluZyZuYnNwO3RoZSZuYnNwO292ZXJoZWFkJm5ic3A7aXMmbmJzcDt0byZuYnNw O2hhdmUmbmJzcDthJm5ic3A7c2NoZW1lJm5ic3A7dXNpbmcmbmJzcDthY2Nlc3MmbmJzcDs8L0RJ Vj4NCjxESVY+dG9rZW5zLiZuYnNwOyZuYnNwO0NsaWVudHMmbmJzcDtjYW4mbmJzcDtoYW5kJm5i c3A7b3V0Jm5ic3A7dG9rZW5zJm5ic3A7KHBvc3NpYmx5Jm5ic3A7d2l0aCZuYnNwO2FuJm5ic3A7 ZXhwaXJhdGlvbiZuYnNwO3RpbWUpJm5ic3A7PC9ESVY+DQo8RElWPndpdGhvdXQmbmJzcDtpbnZv bHZlbWVudCZuYnNwO2Zyb20mbmJzcDt0aGUmbmJzcDtzZXJ2ZXIuJm5ic3A7VGhlJm5ic3A7c2Vy dmVyJm5ic3A7anVzdCZuYnNwO25lZWRzJm5ic3A7dG8mbmJzcDt2ZXJpZnkmbmJzcDt0aGUmbmJz cDt0b2tlbiZuYnNwOzwvRElWPg0KPERJVj53aGVuJm5ic3A7ZGF0YSZuYnNwO2lzJm5ic3A7cmVx dWVzdGVkLjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+LS0mbmJzcDs8L0RJVj4NCjxESVY+Umlj aGFyZCZuYnNwO0FsaW1pPC9ESVY+DQo8RElWPkRlcGFydG1lbnQmbmJzcDtvZiZuYnNwO0NvbXB1 dGVyJm5ic3A7U2NpZW5jZTwvRElWPg0KPERJVj5ZYWxlJm5ic3A7VW5pdmVyc2l0eTwvRElWPg0K PERJVj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvRElW Pg0KPERJVj5kZWNhZGUmbmJzcDttYWlsaW5nJm5ic3A7bGlzdDwvRElWPg0KPERJVj5kZWNhZGVA aWV0Zi5vcmc8L0RJVj4NCjxESVY+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9kZWNhZGU8L0RJVj48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== --Boundary_(ID_ELtB2QsdmLn+gB12WYiyqA)-- From davidbryan@gmail.com Wed Jan 27 10:19:54 2010 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 73B573A67D3 for ; Wed, 27 Jan 2010 10:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3asGigB+ylg1 for ; Wed, 27 Jan 2010 10:19:53 -0800 (PST) Received: from mail-yx0-f194.google.com (mail-yx0-f194.google.com [209.85.210.194]) by core3.amsl.com (Postfix) with ESMTP id 144C93A67CC for ; Wed, 27 Jan 2010 10:19:53 -0800 (PST) Received: by yxe32 with SMTP id 32so11152890yxe.5 for ; Wed, 27 Jan 2010 10:20:05 -0800 (PST) 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=/thja+j+Vzj1CfMl6qx42kb6eMhevR+1gWJKVKfWJMY=; b=lf8e0Lo/9W0vhkVz12pzLe93viDEQEwZJx2/S8SoTi1lISplITdwm+ny946oDQpmLL KkSI/DmWtZim5QfDiqx2RZyb2UDkrOzT1Boxz6w2WB7RxJRJ+lGglxCWIw93UZscIDe5 51VC9GBpLewLSKFAcGyIFqEiPi4NIQsfNgDHI= 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=kLkwU6aB1FOmm1Xc39gHk93kYGLg8VWb0hAAvXMHdwQZNUgZ86YggGmUzOpxdYzi+h UdwMCDl0k0AQe0wtAFJGsSxZ6x9QSeZ1g5ER2JzpfIuqEyMmI4dhybVksHb+Za67feas B2QlVioTW4Qy9TCYKNAxw2k0Q5xo2OdfIX+FM= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.151.89.42 with SMTP id r42mr12137746ybl.272.1264616404969; Wed, 27 Jan 2010 10:20:04 -0800 (PST) In-Reply-To: References: <201001221658.24381.richard.alimi@yale.edu> <8b2769931001261138u43e6222ifa38d3cda3a258e6@mail.gmail.com> <201001261527.24439.richard.alimi@yale.edu> <8b2769931001261248n293d1300q5da866d87f6f905e@mail.gmail.com> Date: Wed, 27 Jan 2010 13:20:04 -0500 X-Google-Sender-Auth: 96644a55332e1843 Message-ID: <8b2769931001271020t487205c7t37c94ad044d237a@mail.gmail.com> From: "David A. Bryan" To: "Schmidt, Christian 1. (NSN - DE/Munich)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: decade@ietf.org Subject: Re: [decade] Updated DECADE Charter 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, 27 Jan 2010 18:19:54 -0000 I'm actually not too picky on what we say, as long as the intent is there. "Management" certainly may be the wrong word, and your suggestion is fine by me as well. Mostly I just noticed that the original version appeared missing a word and/or some punctuation from a grammatical perspective. David On Wed, Jan 27, 2010 at 4:20 AM, Schmidt, Christian 1. (NSN - DE/Munich) wrote: > Hi Bryan, > >>Interestingly, I noticed another very minor nit as I re-read that >>section in the original. The first bullet in the out of scope items is >>missing something. It says "Copyright protected or illegal content For >>example...". Maybe that should be "Copyright protected or illegal >>content management. For example..."? > > What do you mean with illegal content management? Transcoding? Content ma= nipulation? > Perhaps, this could be added as additional point, but this was not meant = here. > With illegal content we mean e.g. certain kinds of pornography. > > So my proposal would be: > "Copyright protected or illegal content and illicit content manipulation.= " > What do you think about? > > BR > Christian > > > > > -----Original Message----- > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf = Of ext David A. Bryan > Sent: Tuesday, January 26, 2010 9:48 PM > To: Richard Alimi > Cc: decade@ietf.org > Subject: Re: [decade] Updated DECADE Charter > > Thanks for getting back so quickly. I think the alternate text > sections you suggest below clarify things nicely. Comments (mostly > just me agreeing with you ;) ) inline below: > > On Tue, Jan 26, 2010 at 3:27 PM, Richard Alimi w= rote: >> Hi David, >> >> First of all, thank you very much for taking the time to read the new pr= oposed >> charter and provide feedback. =A0Responses inline below: >> >>> Overall, while much better, there is still a bit of lack of clarity >>> about what is being developed and what is definitely out of scope from >>> a protocol perspective. I think the text is good that says we will try >>> to re-use something (NFS, WebDav, etc.), for example, in para 4 it >>> says that the WG will design a protocol that "leverage existing IETF >>> protocols where possible, in particular for storing retrieving and >>> managing data". However, I think folks could be confused when they >>> then go on to read the third point for out of scope items is >>> developing a new protocol to deliver content. >>> >>> My understanding is that there may be new work on a protocol to >>> specify policies, and provide control messages and signaling around >>> the transfers (possibly again reusing/extending or incoprorating some >>> existing protocols), but that we would definitely reuse something for >>> the actual transport, hence the third bullet in the out of scope >>> items. >> >> Your understanding of the intent is correct. >> >> The intended meaning of the last "out of scope" item was to underline th= e fact >> that we don't want to design another NFS or WebDAV for transferring data= , but >> instead re-use them. =A0Perhaps it could be clarified as: >> >> =A0"Developing a new protocol for data transport between P2P application= s and >> =A0in-network storage." >> >> Do you think this clarifies it enough? > > I think that is much better. The clarification that the data transport > itself won't be reinvented is really the key point (and something I > mentioned in the BoF a couple times, so glad to see it here.) > > Interestingly, I noticed another very minor nit as I re-read that > section in the original. The first bullet in the out of scope items is > missing something. It says "Copyright protected or illegal content For > example...". Maybe that should be "Copyright protected or illegal > content management. For example..."? > >>> Similarly, the last sentence in para 3 could be read to imply >>> we can't reuse HTTP, NFS, etc., when I *believe* the intent is to note >>> that if they are reused, they may need to be extended or used as a >>> part of a solution. >> >> I see the ambiguity here. Perhaps that sentence can be made more explici= t by >> saying: >> =A0Though there are existing data access protocols (e.g., HTTP, NFS, Web= DAV), >> =A0they currently lack capabilities needed when applied in this context. >> As part of DECADE, we aim to fill in the gaps and make certain protocols >> usable in this context. > > Sounds pretty good. I would imagine we might extend, or might have a > new protocol that makes use of (as part of it, either embedded or in > concert with) an existing protocol to meet that goal. > >> >>> I think we need a bit more clarity to distinguish >>> between where we may reuse or may develop new (access control, >>> resource control, etc.), and where we are definitely using existing >>> (actual transport, from my recollection) and make that a bit more >>> crisp for a newcomer to this group. >> >> In regards to identifying where we may need to extend the underlying pro= tocol, >> we currently we have this text: >> >> =A0 =A0If the underlying protocol does not support certain data manageme= nt >> =A0 =A0operations, DECADE may seek to define such extensions and present= them to >> =A0 =A0the respective working groups or create an Individual Submission = if no >> =A0 =A0active working group exists. >> >> We are operating under the assumption that the underlying protocol will >> already support read/write (i.e., data transport), and may also have som= e >> operations for managing whatever data is currently stored. However, ther= e may >> be certain resource management operations that are not currently present= . This >> is why we felt it necessary to call out that we may need to extend the s= et of >> operations in the underlying protocol, and provide an avenue for doing t= hat. >> >> [As a side note, re-reading the existing text, I believe that "data >> management" should be changed to "resource management" since there may e= xist a >> need to manage resources other than data (e.g., bandwidth, connections).= ] > > Definitely agree here and support that change. > >> To make this distinction more clear, perhaps we can say something like: >> >> =A0 =A0... The underlying protocol will be used wherever possible to sup= port >> =A0 =A0DECADE's required operations. It is assumed that the underlying p= rotocol >> =A0 =A0already supports data transport for reading from and writing to i= n-network >> =A0 =A0storage. If the existing underlying protocol does not support cer= tain >> =A0 =A0resource management operations, DECADE may seek to define such ex= tensions >> =A0 =A0and present them to the respective working groups or create an In= dividual >> =A0 =A0Submission if no active working group exists. ... > > I think this makes sense. > > Thanks! > > David > >>> The last two sentences in para 2, when read together, read very oddly: >>> >>> "For P2P applications, closed P2P caching systems limit effective >>> utilization of in-network storage. P2P protocols may be entirely >>> unsupported, and applications may be better-equipped to decide how >>> in-network storage is used to meet their specific requirements (e.g., >>> data placement, access control and resource control)." >>> >>> maybe this? >>> >>> "For P2P applications, closed P2P caching systems limit effective >>> utilization of in-network storage. Some P2P protocols may be entirely >>> unsupported by a particular caching system. Additionally, applications >>> may be better-equipped to decide how in-network storage is used to >>> meet their specific requirements (e.g., data placement, access control >>> and resource control)." >> >> This makes sense. This can be incorporated in the next revision. >> >>> In paragraph 4, I think maybe we are missing a word in this sentence: >>> >>> "...(2) specify access control for storing and retrieving data >>> suitable for a P2P environment ..." >>> >>> access control settings? values? >> >> "policies" may characterize this better. =A0This can be added. > > Yep. I couldn't think of the right word, but policies seems like the > right choice to me. > >>> The last sentence in the fourth WG item is a bit unclear as well: >>> >>> "This group may also create a profile of necessary operations from an >>> existing IETF protocol to reduce the complexity and software footprint >>> of a compliant implementation." >>> >>> I think we should be clear about what we mean by compliant >>> implementation here (i.e., compliant with the existing protocol or >>> with DECADE). I think we mean a compliant DECADE implementation. >> >> Yes, we do mean a compliant DECADE implementation. This can be clarified= . >> >>> As always, goals and milestones are always wild guesses. Spoken as >>> someone who chairs another group that currently appears to have >>> significantly expired milestones (now that I noticed, guess I better >>> go fix that...oops), these seem really, really aggressive... >>> >>> Overall, I think this is getting much closer to ready. Great job, and >>> looking forward to hearing comments from others. >> >> We are also looking forward to hearing comments from others as well :) >> >> -- >> Richard Alimi >> Department of Computer Science >> Yale University >> > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > From melodysong@huawei.com Thu Jan 28 18:56:01 2010 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 006293A69A3 for ; Thu, 28 Jan 2010 18:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vq8W5YO-IM1I for ; Thu, 28 Jan 2010 18:55:59 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id B8E663A692A for ; Thu, 28 Jan 2010 18:55:58 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWZ00K3PMTAYR@szxga03-in.huawei.com> for decade@ietf.org; Fri, 29 Jan 2010 10:55:58 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWZ006O7MTA2U@szxga03-in.huawei.com> for decade@ietf.org; Fri, 29 Jan 2010 10:55:58 +0800 (CST) Received: from s64081a ([10.164.12.49]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KWZ00EA8MT0WU@szxml04-in.huawei.com> for decade@ietf.org; Fri, 29 Jan 2010 10:55:58 +0800 (CST) Date: Fri, 29 Jan 2010 10:55:48 +0800 From: Song Haibin In-reply-to: To: "'Strandberg, Ove (NSN - FI/Espoo)'" , 'ext Enrico Marocco' , 'Richard Alimi' Message-id: <024401caa08e$921a0760$310ca40a@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: AcqfN8VsiuqE2r8KQ0qgOs229v+PcAAANeEgAFUN20A= Cc: decade@ietf.org Subject: Re: [decade] Updated DECADE Charter 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, 29 Jan 2010 02:56:01 -0000 Hi Ove, Thanks for the good comment. It is very useful if the protocol can be used by other types of applications. But If you consider other applications for the first step, you have to incorporate other features. For example, you may need replicas in the in-network storage to guarantee QoS. I prefer to focus on P2P applications initially, but keep other applications in mind, so that later extensions can be made to let better integration with other applications. Xie Xie, Haibin > -----Original Message----- > From: decade-bounces@ietf.org > [mailto:decade-bounces@ietf.org] On Behalf Of Strandberg, Ove > (NSN - FI/Espoo) > Sent: Wednesday, January 27, 2010 6:13 PM > To: ext Enrico Marocco; Richard Alimi > Cc: decade@ietf.org > Subject: Re: [decade] Updated DECADE Charter > > Hi all, > > At the pre-BOF in Stockholm also other applications than P2P > was discussed. I probably missed some of the discussion in > Hiroshima, but I would appriciate shifting focus from P2P > intpo more generic use of network storage, eg. We should not > get into too P2P specific solution. > The statement: > > "The protocol will be focused on P2P applications, though it > may also be used in other types of applications." > > Could be reworked: > > "The protocol will be focused on P2P applications, though it > should be generic to allow usage in other types of applications also." > > Br, > > +Ove > > Ps. I also have background in Network of Information in 4WARD project. > Ds. > > >-----Original Message----- > >From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On > >Behalf Of ext Enrico Marocco > >Sent: 27 January, 2010 12:02 > >To: Richard Alimi > >Cc: decade@ietf.org > >Subject: Re: [decade] Updated DECADE Charter > > > >Thanks for putting this together! > > > >In general I like text, but one thing I think we should do very > >carefully is to precisely list what we are sure is missing from > >existing protocols -- fine grained access and resource > control, right? > >-- as, at the end of the day, that will be the reason why > the IESG may > >decide to charter a new WG. To this extent, I'd prefer to be more > >explicit, at the risk of being redundant, e.g. in the last > sentence of > >paragraph 3: > > > > Though there are existing data access protocols (e.g., HTTP, NFS, > > WebDAV), they lack capabilities needed when applied in this context. > > > >What about replacing it with something along this line? > > > > Though there are existing data access protocols (e.g., HTTP, NFS, > > WebDAV), they lack capabilities for fine-grained access and > resource > > control that are essential for today's advanced P2P algorithms. > > > >Enrico > > > >Richard Alimi wrote: > >> Hi All, > >> > >> We have been working on a new charter with a refined scope and > >> incorporating past discussion on the mailing list. It would be > >> wonderful to hear comments on the new proposed charter. > >> > >> > >============================================================= > ========= > >> == > >> > >> DECoupled Application Data Enroute > >> > >> Description of Working Group: > >> > >> Peer-to-Peer (P2P) applications, including both P2P > >streaming and P2P > >> file- sharing applications, make up a large fraction of > >traffic in the > >> Internet today. One way to reduce access network and/or > cross-domain > >> bandwidth usage by P2P applications is to introduce storage > >capabilities in the networks. > >> Allowing P2P applications to store and retrieve data from inside > >> networks can reduce traffic on the last-mile uplink, as well > >as backbone and transit links. > >> > >> Existing P2P caches often implement the specific P2P application > >> protocols to operate transparently or act as super peers to > >provide in-network storage. > >> However, this approach poses challenges to both P2P cache > >vendors and > >> P2P application developers. For P2P cache vendors, the > >challenge is to > >> support a variety of exisiting and evolving protocols. For P2P > >> applications, closed P2P caching systems limit effective > utilization > >> of in-network storage. Some P2P protocols may be entirely > >unsupported, > >> and applications may be better-equipped to decide how in-network > >> storage is used to meet their specific requirements (e.g., > >data placement, access control and resource control). > >> > >> Both of these challenges can be effectively addressed by using an > >> open, standard protocol to access in-network storage. P2P > >applications > >> can store and retrieve content in the in-network storage, > as well as > >> control resources (e.g., bandwidth, connections) consumed by > >peers in > >> a P2P application. As a simple example, a peer can choose > to store > >> content in the in-network storage, and direct other peers to > >retrieve > >> from that location, reducing last-mile link usage. Though > there are > >> existing data access protocols (e.g., HTTP, NFS, WebDAV), > >they lack capabilities needed when applied in this context. > >> > >> The Working Group (WG) will design and specify a standard > >protocol for > >> P2P applications to utilize in-network storage. The protocol will > >> include operations for a P2P application to (1) store, > retrieve, and > >> manage data, (2) specify access control for storing and retrieving > >> data suitable for a P2P environment with peers across multiple > >> administrative and security domains, and (3) indicate > >resource control policies for storing and retrieving data. > >> The WG will leverage existing IETF protocols where possible, in > >> particular for storing, retrieving, and managing data. > >> > >> This WG will focus mainly on the protocol between the in-network > >> storage and P2P applications. The protocol will be focused on P2P > >> applications, though it may also be used in other types of > >applications. > >> > >> The WG will focus on the following work items: > >> > >> - A "problem statement" document. This document provides a > >description of the > >> problem and common terminology. > >> > >> - A requirements document. This document lists the > >requirements for the > >> in-network storage service (e.g., supported operations) > >and the protocol to > >> support it. > >> > >> - A survey document. This document will survey existing > >related mechanisms > >> and protocols (e.g., HTTP, NFS, and WebDAV), and evaluate their > >> applicability and effectiveness. > >> > >> - A signaling protocol for storing, retrieving, and managing > >data as well as > >> specifying both access control and resource control > policies in the > >> in-network storage pertaining to that data. Data storage, > >retrieval, and > >> management may be provided by an existing IETF protocol. > >If the underlying > >> protocol does not support certain data management > >operations, DECADE may > >> seek to define such extensions and present them to the > >respective working > >> groups or create an Individual Submission if no active > >working group exists. > >> This group may also create a profile of necessary > >operations from an > >> existing IETF protocol to reduce the complexity and > >software footprint of a > >> compliant implementation. > >> > >> The WG will not limit itself to a single underlying > >protocol since different > >> underlying protocols may have varying implementation costs > >and performance > >> tradeoffs. To keep interoperability manageable, a small > >number of specific, > >> targeted, underlying protocols will be used. NFS and > >WebDAV are initial > >> targets and others may be incorporated with WG consensus. > >> > >> - An informational document describing the integration of > >DECADE with existing > >> P2P applications (e.g., integration with BitTorrent). > >> > >> The following issues are not considered in the current scope > >of the WG: > >> > >> - Copyright protected or illegal content > >> For example, one possibility is that that an in-network > >storage system may > >> have system-wide ingress and egress filters to implement > >policies related to > >> copyrighted and illegal content. This is outside the > >scope of this working > >> group. > >> > >> - Locating the "best" in-network storage location from which > >to retrieve > >> content if there are more than one location can provide > >the same content. > >> > >> - Developing a new protocol to deliver content between P2P > >application and > >> in-network storage. > >> > >> Goals and Milestones: > >> > >> May 2010 Working Group Last Call for problem statement Aug 2010 > >> Submit problem statement to IESG as Informational Aug 2010 > Working > >> Group Last Call for requirements document Feb 2011 Submit > >> requirements document to IESG as Informational May 2011 > >Working Group > >> Last Call for survey document Aug 2011 Working Group Last > Call for > >> in-network storage access protocol Aug 2011 Submit survey > >document to > >> IESG as Informational Nov 2011 Submit in-network storage access > >> protocol to IESG as Proposed > >> Standard > >> > >> > >============================================================= > ========= > >> == > >> > >> Thanks! > > > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > From ove.strandberg@nsn.com Fri Jan 29 02:41:07 2010 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 0E7303A6810 for ; Fri, 29 Jan 2010 02:41:07 -0800 (PST) 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 WV0myrN74JcQ for ; Fri, 29 Jan 2010 02:41:05 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id F0B0C3A68CB for ; Fri, 29 Jan 2010 02:41:04 -0800 (PST) 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 o0TAfLaO002216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 29 Jan 2010 11:41:21 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o0TAfLi8008044; Fri, 29 Jan 2010 11:41:21 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 11:41:20 +0100 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, 29 Jan 2010 12:41:25 +0200 Message-ID: In-Reply-To: <024401caa08e$921a0760$310ca40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] Updated DECADE Charter Thread-Index: AcqfN8VsiuqE2r8KQ0qgOs229v+PcAAANeEgAFUN20AAEAtPcA== References: <024401caa08e$921a0760$310ca40a@china.huawei.com> From: "Strandberg, Ove (NSN - FI/Espoo)" To: "ext Song Haibin" , "ext Enrico Marocco" , "Richard Alimi" X-OriginalArrivalTime: 29 Jan 2010 10:41:21.0001 (UTC) FILETIME=[9875C590:01CAA0CF] Cc: decade@ietf.org Subject: Re: [decade] Updated DECADE Charter 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, 29 Jan 2010 10:41:07 -0000 Hi Haibin, Thanks for your comments. My main concern with P2P as use case is that other interaction towards a network storage other than originating from a P2P client will not be considered. I could easily imagine the benefit of network storage for examples for applications like Spotify, Youtube, IPTV etc.. They can potentially be interedsted in memory utilization too. Thus there are other potential use of a network storage protocol. The relationship of these towards a network storage looks different from a P2P client perspective and designing from only P2P in first step potentially limiting.=20 This use case concern is of principal matter (me thinks) and the charter should reflect this already now. This change does not change the fact that most interest might be on solving the P2P use case, but there are more use cases that should be included in the charter description. Br, +Ove >-----Original Message----- >From: ext Song Haibin [mailto:melodysong@huawei.com]=20 >Sent: 29 January, 2010 04:56 >To: Strandberg, Ove (NSN - FI/Espoo); 'ext Enrico Marocco';=20 >'Richard Alimi' >Cc: decade@ietf.org >Subject: RE: [decade] Updated DECADE Charter > > >Hi Ove, > >Thanks for the good comment. It is very useful if the protocol=20 >can be used by other types of applications. But If you=20 >consider other applications for the first step, you have to=20 >incorporate other features. For example, you may need=20 >replicas in the in-network storage to guarantee QoS. I prefer=20 >to focus on P2P applications initially, but keep other=20 >applications in mind, so that later extensions can be made to=20 >let better integration with other applications. > >Xie Xie, >Haibin >=20 > >> -----Original Message----- >> From: decade-bounces@ietf.org >> [mailto:decade-bounces@ietf.org] On Behalf Of Strandberg, Ove (NSN -=20 >> FI/Espoo) >> Sent: Wednesday, January 27, 2010 6:13 PM >> To: ext Enrico Marocco; Richard Alimi >> Cc: decade@ietf.org >> Subject: Re: [decade] Updated DECADE Charter >>=20 >> Hi all, >>=20 >> At the pre-BOF in Stockholm also other applications than P2P was=20 >> discussed. I probably missed some of the discussion in=20 >Hiroshima, but=20 >> I would appriciate shifting focus from P2P intpo more generic use of=20 >> network storage, eg. We should not get into too P2P specific=20 >solution. >> The statement: >>=20 >> "The protocol will be focused on P2P applications, though it=20 >may also=20 >> be used in other types of applications." >>=20 >> Could be reworked: >>=20 >> "The protocol will be focused on P2P applications, though it=20 >should be=20 >> generic to allow usage in other types of applications also." >>=20 >> Br, >>=20 >> +Ove >>=20 >> Ps. I also have background in Network of Information in=20 >4WARD project. >> Ds.=20 >>=20 >> >-----Original Message----- >> >From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On=20 >> >Behalf Of ext Enrico Marocco >> >Sent: 27 January, 2010 12:02 >> >To: Richard Alimi >> >Cc: decade@ietf.org >> >Subject: Re: [decade] Updated DECADE Charter >> > >> >Thanks for putting this together! >> > >> >In general I like text, but one thing I think we should do very=20 >> >carefully is to precisely list what we are sure is missing from=20 >> >existing protocols -- fine grained access and resource >> control, right?=20 >> >-- as, at the end of the day, that will be the reason why >> the IESG may >> >decide to charter a new WG. To this extent, I'd prefer to be more=20 >> >explicit, at the risk of being redundant, e.g. in the last >> sentence of >> >paragraph 3: >> > >> > Though there are existing data access protocols (e.g., HTTP, NFS,=20 >> > WebDAV), they lack capabilities needed when applied in=20 >this context. >> > >> >What about replacing it with something along this line? >> > >> > Though there are existing data access protocols (e.g., HTTP, NFS,=20 >> > WebDAV), they lack capabilities for fine-grained access and >> resource >> > control that are essential for today's advanced P2P algorithms. >> > >> >Enrico >> > >> >Richard Alimi wrote: >> >> Hi All, >> >>=20 >> >> We have been working on a new charter with a refined scope and=20 >> >> incorporating past discussion on the mailing list. It would be=20 >> >> wonderful to hear comments on the new proposed charter. >> >>=20 >> >>=20 >> = >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> =3D=3D >> >>=20 >> >> DECoupled Application Data Enroute >> >>=20 >> >> Description of Working Group: >> >>=20 >> >> Peer-to-Peer (P2P) applications, including both P2P >> >streaming and P2P >> >> file- sharing applications, make up a large fraction of >> >traffic in the >> >> Internet today. One way to reduce access network and/or >> cross-domain >> >> bandwidth usage by P2P applications is to introduce storage >> >capabilities in the networks. >> >> Allowing P2P applications to store and retrieve data from inside=20 >> >> networks can reduce traffic on the last-mile uplink, as well >> >as backbone and transit links. >> >>=20 >> >> Existing P2P caches often implement the specific P2P application=20 >> >> protocols to operate transparently or act as super peers to >> >provide in-network storage. >> >> However, this approach poses challenges to both P2P cache >> >vendors and >> >> P2P application developers. For P2P cache vendors, the >> >challenge is to >> >> support a variety of exisiting and evolving protocols. For P2P=20 >> >> applications, closed P2P caching systems limit effective >> utilization >> >> of in-network storage. Some P2P protocols may be entirely >> >unsupported, >> >> and applications may be better-equipped to decide how in-network=20 >> >> storage is used to meet their specific requirements (e.g., >> >data placement, access control and resource control). >> >>=20 >> >> Both of these challenges can be effectively addressed by using an=20 >> >> open, standard protocol to access in-network storage. P2P >> >applications >> >> can store and retrieve content in the in-network storage, >> as well as >> >> control resources (e.g., bandwidth, connections) consumed by >> >peers in >> >> a P2P application. As a simple example, a peer can choose >> to store >> >> content in the in-network storage, and direct other peers to >> >retrieve >> >> from that location, reducing last-mile link usage. Though >> there are >> >> existing data access protocols (e.g., HTTP, NFS, WebDAV), >> >they lack capabilities needed when applied in this context. >> >>=20 >> >> The Working Group (WG) will design and specify a standard >> >protocol for >> >> P2P applications to utilize in-network storage. The=20 >protocol will=20 >> >> include operations for a P2P application to (1) store, >> retrieve, and >> >> manage data, (2) specify access control for storing and=20 >retrieving=20 >> >> data suitable for a P2P environment with peers across multiple=20 >> >> administrative and security domains, and (3) indicate >> >resource control policies for storing and retrieving data. >> >> The WG will leverage existing IETF protocols where possible, in=20 >> >> particular for storing, retrieving, and managing data. >> >>=20 >> >> This WG will focus mainly on the protocol between the in-network=20 >> >> storage and P2P applications. The protocol will be=20 >focused on P2P=20 >> >> applications, though it may also be used in other types of >> >applications. >> >>=20 >> >> The WG will focus on the following work items: >> >>=20 >> >> - A "problem statement" document. This document provides a >> >description of the >> >> problem and common terminology. >> >>=20 >> >> - A requirements document. This document lists the >> >requirements for the >> >> in-network storage service (e.g., supported operations) >> >and the protocol to >> >> support it.=20 >> >>=20 >> >> - A survey document. This document will survey existing >> >related mechanisms >> >> and protocols (e.g., HTTP, NFS, and WebDAV), and evaluate their=20 >> >> applicability and effectiveness. >> >>=20 >> >> - A signaling protocol for storing, retrieving, and managing >> >data as well as >> >> specifying both access control and resource control >> policies in the >> >> in-network storage pertaining to that data. Data storage, >> >retrieval, and >> >> management may be provided by an existing IETF protocol.=20 >> >If the underlying >> >> protocol does not support certain data management >> >operations, DECADE may >> >> seek to define such extensions and present them to the >> >respective working >> >> groups or create an Individual Submission if no active >> >working group exists.=20 >> >> This group may also create a profile of necessary >> >operations from an >> >> existing IETF protocol to reduce the complexity and >> >software footprint of a >> >> compliant implementation. >> >>=20 >> >> The WG will not limit itself to a single underlying >> >protocol since different >> >> underlying protocols may have varying implementation costs >> >and performance >> >> tradeoffs. To keep interoperability manageable, a small >> >number of specific, >> >> targeted, underlying protocols will be used. NFS and >> >WebDAV are initial >> >> targets and others may be incorporated with WG consensus. >> >>=20 >> >> - An informational document describing the integration of >> >DECADE with existing >> >> P2P applications (e.g., integration with BitTorrent). >> >>=20 >> >> The following issues are not considered in the current scope >> >of the WG: >> >>=20 >> >> - Copyright protected or illegal content >> >> For example, one possibility is that that an in-network >> >storage system may >> >> have system-wide ingress and egress filters to implement >> >policies related to >> >> copyrighted and illegal content. This is outside the >> >scope of this working >> >> group. >> >>=20 >> >> - Locating the "best" in-network storage location from which >> >to retrieve >> >> content if there are more than one location can provide >> >the same content. >> >>=20 >> >> - Developing a new protocol to deliver content between P2P >> >application and >> >> in-network storage. >> >>=20 >> >> Goals and Milestones: >> >>=20 >> >> May 2010 Working Group Last Call for problem statement Aug 2010=20 >> >> Submit problem statement to IESG as Informational Aug 2010 >> Working >> >> Group Last Call for requirements document Feb 2011 Submit=20 >> >> requirements document to IESG as Informational May 2011 >> >Working Group >> >> Last Call for survey document Aug 2011 Working Group Last >> Call for >> >> in-network storage access protocol Aug 2011 Submit survey >> >document to >> >> IESG as Informational Nov 2011 Submit in-network storage access=20 >> >> protocol to IESG as Proposed >> >> Standard >> >>=20 >> >>=20 >> = >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> =3D=3D >> >>=20 >> >> Thanks! >> > >> _______________________________________________ >> decade mailing list >> decade@ietf.org >> https://www.ietf.org/mailman/listinfo/decade >>=20 > > > From guyingjie@huawei.com Fri Jan 29 04:09:10 2010 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 DBA663A693E for ; Fri, 29 Jan 2010 04:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oc3jihWByf-7 for ; Fri, 29 Jan 2010 04:09:09 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id AE0823A687B for ; Fri, 29 Jan 2010 04:09:07 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KX000BVVCFIQ2@szxga03-in.huawei.com> for decade@ietf.org; Fri, 29 Jan 2010 20:09:18 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KX000ESDCFIGS@szxga03-in.huawei.com> for decade@ietf.org; Fri, 29 Jan 2010 20:09: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 <0KX000MNGCFI7F@szxml06-in.huawei.com> for decade@ietf.org; Fri, 29 Jan 2010 20:09:18 +0800 (CST) Date: Fri, 29 Jan 2010 20:09:16 +0800 From: "Y.J. Gu" In-reply-to: To: "'Strandberg, Ove (NSN - FI/Espoo)'" , 'ext Song Haibin' , 'ext Enrico Marocco' , 'Richard Alimi' Message-id: <00d301caa0db$e164c4c0$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: AcqfN8VsiuqE2r8KQ0qgOs229v+PcAAANeEgAFUN20AAEAtPcAADUK3g Cc: decade@ietf.org Subject: Re: [decade] Updated DECADE Charter 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, 29 Jan 2010 12:09:10 -0000 Hi, I agree with taking other applications into consideration at the first beginning. At least we should analyze whether compatible with other applications will make significant difference, comparing with the protocol/mechanism designed exclusively for P2P. If we donot want to make this effort, then how about just removing words like "can be used by other applications". My 2 cents. Regards Yingjie Gu > -----Original Message----- > From: decade-bounces@ietf.org > [mailto:decade-bounces@ietf.org] On Behalf Of Strandberg, Ove > (NSN - FI/Espoo) > Sent: Friday, January 29, 2010 6:41 PM > To: ext Song Haibin; ext Enrico Marocco; Richard Alimi > Cc: decade@ietf.org > Subject: Re: [decade] Updated DECADE Charter > > Hi Haibin, > > Thanks for your comments. > > My main concern with P2P as use case is that other > interaction towards a network storage other than originating > from a P2P client will not be considered. I could easily > imagine the benefit of network storage for examples for > applications like Spotify, Youtube, IPTV etc.. They can > potentially be interedsted in memory utilization too. Thus > there are other potential use of a network storage protocol. > The relationship of these towards a network storage looks > different from a P2P client perspective and designing from > only P2P in first step potentially limiting. > > This use case concern is of principal matter (me thinks) and > the charter should reflect this already now. This change does > not change the fact that most interest might be on solving > the P2P use case, but there are more use cases that should be > included in the charter description. > > Br, > > +Ove > > >-----Original Message----- > >From: ext Song Haibin [mailto:melodysong@huawei.com] > >Sent: 29 January, 2010 04:56 > >To: Strandberg, Ove (NSN - FI/Espoo); 'ext Enrico Marocco'; 'Richard > >Alimi' > >Cc: decade@ietf.org > >Subject: RE: [decade] Updated DECADE Charter > > > > > >Hi Ove, > > > >Thanks for the good comment. It is very useful if the > protocol can be > >used by other types of applications. But If you consider other > >applications for the first step, you have to incorporate other > >features. For example, you may need replicas in the > in-network storage > >to guarantee QoS. I prefer to focus on P2P applications > initially, but > >keep other applications in mind, so that later extensions > can be made > >to let better integration with other applications. > > > >Xie Xie, > >Haibin > > > > > >> -----Original Message----- > >> From: decade-bounces@ietf.org > >> [mailto:decade-bounces@ietf.org] On Behalf Of Strandberg, > Ove (NSN - > >> FI/Espoo) > >> Sent: Wednesday, January 27, 2010 6:13 PM > >> To: ext Enrico Marocco; Richard Alimi > >> Cc: decade@ietf.org > >> Subject: Re: [decade] Updated DECADE Charter > >> > >> Hi all, > >> > >> At the pre-BOF in Stockholm also other applications than P2P was > >> discussed. I probably missed some of the discussion in > >Hiroshima, but > >> I would appriciate shifting focus from P2P intpo more > generic use of > >> network storage, eg. We should not get into too P2P specific > >solution. > >> The statement: > >> > >> "The protocol will be focused on P2P applications, though it > >may also > >> be used in other types of applications." > >> > >> Could be reworked: > >> > >> "The protocol will be focused on P2P applications, though it > >should be > >> generic to allow usage in other types of applications also." > >> > >> Br, > >> > >> +Ove > >> > >> Ps. I also have background in Network of Information in > >4WARD project. > >> Ds. > >> > >> >-----Original Message----- > >> >From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On > >> >Behalf Of ext Enrico Marocco > >> >Sent: 27 January, 2010 12:02 > >> >To: Richard Alimi > >> >Cc: decade@ietf.org > >> >Subject: Re: [decade] Updated DECADE Charter > >> > > >> >Thanks for putting this together! > >> > > >> >In general I like text, but one thing I think we should do very > >> >carefully is to precisely list what we are sure is missing from > >> >existing protocols -- fine grained access and resource > >> control, right? > >> >-- as, at the end of the day, that will be the reason why > >> the IESG may > >> >decide to charter a new WG. To this extent, I'd prefer to be more > >> >explicit, at the risk of being redundant, e.g. in the last > >> sentence of > >> >paragraph 3: > >> > > >> > Though there are existing data access protocols (e.g., > HTTP, NFS, > >> > WebDAV), they lack capabilities needed when applied in > >this context. > >> > > >> >What about replacing it with something along this line? > >> > > >> > Though there are existing data access protocols (e.g., > HTTP, NFS, > >> > WebDAV), they lack capabilities for fine-grained access and > >> resource > >> > control that are essential for today's advanced P2P algorithms. > >> > > >> >Enrico > >> > > >> >Richard Alimi wrote: > >> >> Hi All, > >> >> > >> >> We have been working on a new charter with a refined scope and > >> >> incorporating past discussion on the mailing list. It would be > >> >> wonderful to hear comments on the new proposed charter. > >> >> > >> >> > >> >============================================================= > >> ========= > >> >> == > >> >> > >> >> DECoupled Application Data Enroute > >> >> > >> >> Description of Working Group: > >> >> > >> >> Peer-to-Peer (P2P) applications, including both P2P > >> >streaming and P2P > >> >> file- sharing applications, make up a large fraction of > >> >traffic in the > >> >> Internet today. One way to reduce access network and/or > >> cross-domain > >> >> bandwidth usage by P2P applications is to introduce storage > >> >capabilities in the networks. > >> >> Allowing P2P applications to store and retrieve data > from inside > >> >> networks can reduce traffic on the last-mile uplink, as well > >> >as backbone and transit links. > >> >> > >> >> Existing P2P caches often implement the specific P2P > application > >> >> protocols to operate transparently or act as super peers to > >> >provide in-network storage. > >> >> However, this approach poses challenges to both P2P cache > >> >vendors and > >> >> P2P application developers. For P2P cache vendors, the > >> >challenge is to > >> >> support a variety of exisiting and evolving protocols. For P2P > >> >> applications, closed P2P caching systems limit effective > >> utilization > >> >> of in-network storage. Some P2P protocols may be entirely > >> >unsupported, > >> >> and applications may be better-equipped to decide how > in-network > >> >> storage is used to meet their specific requirements (e.g., > >> >data placement, access control and resource control). > >> >> > >> >> Both of these challenges can be effectively addressed > by using an > >> >> open, standard protocol to access in-network storage. P2P > >> >applications > >> >> can store and retrieve content in the in-network storage, > >> as well as > >> >> control resources (e.g., bandwidth, connections) consumed by > >> >peers in > >> >> a P2P application. As a simple example, a peer can choose > >> to store > >> >> content in the in-network storage, and direct other peers to > >> >retrieve > >> >> from that location, reducing last-mile link usage. Though > >> there are > >> >> existing data access protocols (e.g., HTTP, NFS, WebDAV), > >> >they lack capabilities needed when applied in this context. > >> >> > >> >> The Working Group (WG) will design and specify a standard > >> >protocol for > >> >> P2P applications to utilize in-network storage. The > >protocol will > >> >> include operations for a P2P application to (1) store, > >> retrieve, and > >> >> manage data, (2) specify access control for storing and > >retrieving > >> >> data suitable for a P2P environment with peers across multiple > >> >> administrative and security domains, and (3) indicate > >> >resource control policies for storing and retrieving data. > >> >> The WG will leverage existing IETF protocols where possible, in > >> >> particular for storing, retrieving, and managing data. > >> >> > >> >> This WG will focus mainly on the protocol between the > in-network > >> >> storage and P2P applications. The protocol will be > >focused on P2P > >> >> applications, though it may also be used in other types of > >> >applications. > >> >> > >> >> The WG will focus on the following work items: > >> >> > >> >> - A "problem statement" document. This document provides a > >> >description of the > >> >> problem and common terminology. > >> >> > >> >> - A requirements document. This document lists the > >> >requirements for the > >> >> in-network storage service (e.g., supported operations) > >> >and the protocol to > >> >> support it. > >> >> > >> >> - A survey document. This document will survey existing > >> >related mechanisms > >> >> and protocols (e.g., HTTP, NFS, and WebDAV), and > evaluate their > >> >> applicability and effectiveness. > >> >> > >> >> - A signaling protocol for storing, retrieving, and managing > >> >data as well as > >> >> specifying both access control and resource control > >> policies in the > >> >> in-network storage pertaining to that data. Data storage, > >> >retrieval, and > >> >> management may be provided by an existing IETF protocol. > >> >If the underlying > >> >> protocol does not support certain data management > >> >operations, DECADE may > >> >> seek to define such extensions and present them to the > >> >respective working > >> >> groups or create an Individual Submission if no active > >> >working group exists. > >> >> This group may also create a profile of necessary > >> >operations from an > >> >> existing IETF protocol to reduce the complexity and > >> >software footprint of a > >> >> compliant implementation. > >> >> > >> >> The WG will not limit itself to a single underlying > >> >protocol since different > >> >> underlying protocols may have varying implementation costs > >> >and performance > >> >> tradeoffs. To keep interoperability manageable, a small > >> >number of specific, > >> >> targeted, underlying protocols will be used. NFS and > >> >WebDAV are initial > >> >> targets and others may be incorporated with WG consensus. > >> >> > >> >> - An informational document describing the integration of > >> >DECADE with existing > >> >> P2P applications (e.g., integration with BitTorrent). > >> >> > >> >> The following issues are not considered in the current scope > >> >of the WG: > >> >> > >> >> - Copyright protected or illegal content > >> >> For example, one possibility is that that an in-network > >> >storage system may > >> >> have system-wide ingress and egress filters to implement > >> >policies related to > >> >> copyrighted and illegal content. This is outside the > >> >scope of this working > >> >> group. > >> >> > >> >> - Locating the "best" in-network storage location from which > >> >to retrieve > >> >> content if there are more than one location can provide > >> >the same content. > >> >> > >> >> - Developing a new protocol to deliver content between P2P > >> >application and > >> >> in-network storage. > >> >> > >> >> Goals and Milestones: > >> >> > >> >> May 2010 Working Group Last Call for problem statement > Aug 2010 > >> >> Submit problem statement to IESG as Informational Aug 2010 > >> Working > >> >> Group Last Call for requirements document Feb 2011 Submit > >> >> requirements document to IESG as Informational May 2011 > >> >Working Group > >> >> Last Call for survey document Aug 2011 Working Group Last > >> Call for > >> >> in-network storage access protocol Aug 2011 Submit survey > >> >document to > >> >> IESG as Informational Nov 2011 Submit in-network > storage access > >> >> protocol to IESG as Proposed > >> >> Standard > >> >> > >> >> > >> >============================================================= > >> ========= > >> >> == > >> >> > >> >> Thanks! > >> > > >> _______________________________________________ > >> 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 lars.eggert@nokia.com Fri Jan 29 04:21:47 2010 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 291C53A6A04 for ; Fri, 29 Jan 2010 04:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.602 X-Spam-Level: X-Spam-Status: No, score=-6.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 j1J7GgrZDrdk for ; Fri, 29 Jan 2010 04:21:46 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 0BB2B3A6A11 for ; Fri, 29 Jan 2010 04:21:45 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0TCLmSc028358; Fri, 29 Jan 2010 14:22:05 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 14:22:00 +0200 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 14:22:00 +0200 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0TCLw9k032017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jan 2010 14:21:58 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-2-845181744; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <201001270919.18847.richard.alimi@yale.edu> Date: Fri, 29 Jan 2010 14:21:46 +0200 Message-Id: <96A9D5A9-A584-4905-AD5F-58EC1A588E3E@nokia.com> References: <201001221658.24381.richard.alimi@yale.edu> <4B600F16.1000706@telecomitalia.it> <9FEC9AF8-6E4F-45C7-B108-DD70A3190CD2@nokia.com> <201001270919.18847.richard.alimi@yale.edu> To: Richard Alimi X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Fri, 29 Jan 2010 14:21:52 +0200 (EET) X-OriginalArrivalTime: 29 Jan 2010 12:22:00.0239 (UTC) FILETIME=[A8205BF0:01CAA0DD] X-Nokia-AV: Clean Cc: "decade@ietf.org" Subject: Re: [decade] Updated DECADE Charter 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, 29 Jan 2010 12:21:47 -0000 --Apple-Mail-2-845181744 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-1-27, at 16:19, Richard Alimi wrote: > It was my understanding that NFS requires the server to have an = account for=20 > each user that can be granted permissions. Or, are there other models = that=20 > are supported that you could point me to? I'm not the greatest NFS expert in the world either, but IMO the onus is = on the proponents of DECADE to convincingly demonstrate that it would be = better/easier/otherwise useful to create a new protocol here rather than = extending an existing one. Yes, that probably means that someone will = have to familiarize themselves with the existing protocols. Lars= --Apple-Mail-2-845181744 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDEyOTEyMjE0N1owIwYJKoZIhvcNAQkEMRYEFGKigsaLno/tR3nffwuuTl57WRxKMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQCMUnnqObX5WzPoSqJNvGMUntS/o0LUtSQl1/hYIhhv0oZA3hh/tmkNtW24O4ShU9yaUMT/ U9tCYwJndlICedIYIgyePw0zr81GrcFVy9aGIgSaJhamzmjYAICH5etykp2of32X4euElcJwnQlM oCbPFJVQrE1Immxq5LGL4MODTAkR6eRiCcZxSvRXTOL7ijMPWVGa2asi/ydIOJ8Zx395ADFPnG0l MgyZ34WSV77E4QLaI55PLZq3jjfn4KNMMdFgcCnEPiawSCzAPGjZE5XahExBHY5mIXpW7r1ZwCdi ekaem4Sm0TcYoxFPtyehxHoQvkThWy8ZGEMVLIfgW9WxAAAAAAAA --Apple-Mail-2-845181744-- From borje.ohlman@ericsson.com Fri Jan 29 06:43:23 2010 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 073363A6908 for ; Fri, 29 Jan 2010 06:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 svs91F-+L3q8 for ; Fri, 29 Jan 2010 06:43:21 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 32B8A3A697A for ; Fri, 29 Jan 2010 06:43:20 -0800 (PST) X-AuditID: c1b4fb24-b7c64ae000005cb7-a4-4b62f41dfbfd Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 6E.5B.23735.D14F26B4; Fri, 29 Jan 2010 15:43:41 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 15:43:41 +0100 Received: from [127.0.0.1] ([147.214.74.16]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 15:43:41 +0100 Message-ID: <4B62F41A.6060300@ericsson.com> Date: Fri, 29 Jan 2010 15:43:38 +0100 From: =?ISO-8859-1?Q?B=F6rje_Ohlman?= User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Richard Alimi References: <201001221658.24381.richard.alimi@yale.edu> <314AF86E2FDEB9458540143E41EED8CE0E2F85@esealmw103.eemea.ericsson.se> <201001270444.47316.richard.alimi@yale.edu> In-Reply-To: <201001270444.47316.richard.alimi@yale.edu> Content-Type: multipart/alternative; boundary="------------040708020507040100020109" X-OriginalArrivalTime: 29 Jan 2010 14:43:41.0397 (UTC) FILETIME=[73362050:01CAA0F1] X-Brightmail-Tracker: AAAAAA== Cc: decade@ietf.org Subject: Re: [decade] Updated DECADE Charter 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, 29 Jan 2010 14:43:23 -0000 This is a multi-part message in MIME format. --------------040708020507040100020109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Richard, I don't think support for mobility necessarily needs to make things complex, not if it is designed in from the beginning (e.g. see Internet Indirection Infrastructure (i3)), it is when it is added as an afterthought things get complex. That is why I think that support for basic node mobility should at least be considered. I also think the two issues 'copies' and 'mobility' are related to a certain extent. Being able to use locally available copies rather than to have to access 'your own' remote or migrated copy can simplify mobility significantly. Please see further comments in line below. Börje Richard Alimi wrote: > Hi Börje, > > Thanks for taking the time to provide feedback. See below: > > On Wednesday 27 January 2010 4:01:19 am Börje Ohlman wrote: > >> Hi All, >> >> I think this charter starts to look quite good. >> Though here are two issues I would like to see added to it. >> >> 1) How DECADE deals with copies in the in-network storage >> I think it would be good to make clear if the network part of DECADE can >> benefit when multiple users/application stores the same information object >> (e.g. file). Is it then possible for DECADE to store only one copy of the >> information object or is it required to store multiple copies of the same >> object? >> > > While this is an optimization that could be worthwhile, my feeling is that it > does not matter with respect to the protocol between the application and the > storage. If the storage system were to have such a feature, it may be an > implementation detail. Are you envisioning a case where this would surface in > the protocol? > How you refer to an object, e.g. by relative or absolute references, has an influence on how easy it is to identify a copy of an object. If you use relative path names to refer to objects see that two objects are the same. >> 2) Should DECADE support mobility of terminals/users/applications? >> A lot of today's terminals are mobile, e.g. laptops and smartphones. When >> they move should their in-network storage move with them or should access >> to their storage be made by tunneling back to some type of "home storage"? >> > I think this is a good discussion to have and it would be great to get > opinions from others. My personal feeling is to leave automatic data migration > out of scope, since it may make the system quite complicated. In particular, > one of the things we explicitly mentioned as out-of-scope was finding the > "best" in-network storage element. I think that what you mention here for > mobility is somewhat related to this. > If we don't want to get into data migration and trying to find 'the best' copy I would settle to for agreeing that it is ok to use locally available copies if they happens to be around. As I indicated above this could simplify giving some basic support for nodes that are not permanently stationary in the network. >> Finally a formulation I find confusing. >> In §5 it states: >> "The Working Group (WG) will design and specify a standard protocol for P2P >> applications to utilize in-network storage." >> Then in the last bullet of out-of-scope issues it states: >> "Developing a new protocol to deliver content between P2P application and >> in-network storage." >> A new proposal for this statement is: >> "Developing a new protocol for data transport between P2P applications and >> in-network storage." >> I think both these alternatives can easily be seen as contradicting the >> initial statement. >> >> As I understand it, what is out of scope are protocols >> between two p2p applications, e.g. BitTorrent like protocols, >> > Yes - this is out-of-scope. > >> as well as >> protocols between two instances of in-network storage, e.g. for cache >> migration. >> > The protocol between two in-network storage instances is not currently out-of- > scope. One case where such a protocol can be useful in P2P is when both the > uploading and downloading user have in-network storage. See section 5.3.1 of > the current draft of the problem statement for an example: > http://tools.ietf.org/html/draft-song-decade-problem-statement-00 > > In the eventual specification, the actual data transport between two in- > network storages may be done by the underlying protocol, but we may also need > to pass access control / resource control between them as well (which would be > in scope for DECADE). > > >> But protocols for data transport between a p2p application and >> an in-network storage is very much *in* scope. >> > > The idea is that we'd like to be able to use existing storage access protocols > where possible. The candidates that we mention in the charter currently are > NFS and WebDAV. However, in DECADE, we need to pass some additional > information between the user and in-network storage (e.g., resource control > and access control). Do you have suggestions for an alternate wording here? > If the current thinking is that we want to try to find a suitable protocol to be reused I think it is a bit premature to state that developing a new protocol is out of scope before we have even defined the requirements for the functionality of the new protocol. Börje --------------040708020507040100020109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Richard,

I don't think support for mobility necessarily needs to make things complex, not if it is designed in from the beginning (e.g. see Internet Indirection Infrastructure (i3)), it is when it is added as an afterthought things get complex. That is why I think that support for basic node mobility should at least be considered.

I also think the two issues 'copies' and  'mobility' are related to a certain extent. Being able to use locally available copies rather than to have to access 'your own' remote or migrated copy can simplify mobility significantly.

Please see further comments in line below.

    Börje

Richard Alimi wrote: 
Hi Börje,

Thanks for taking the time to provide feedback. See below:

On Wednesday 27 January 2010 4:01:19 am Börje Ohlman wrote:
  
Hi All,

I think this charter starts to look quite good.
Though here are two issues I would like to see added to it.

1) How DECADE deals with copies in the in-network storage
I think it would be good to make clear if the network part of DECADE can
 benefit when multiple users/application stores the same information object
 (e.g. file). Is it then possible for DECADE to store only one copy of the
 information object or is it required to store multiple copies of the same
 object?
    

While this is an optimization that could be worthwhile, my feeling is that it 
does not matter with respect to the protocol between the application and the 
storage.  If the storage system were to have such a feature, it may be an 
implementation detail.  Are you envisioning a case where this would surface in 
the protocol?
How you refer to an object, e.g. by relative or absolute references, has an influence on how easy it is to identify a copy of an object. If you use relative path names to refer to objects see that two objects are the same.
2) Should DECADE support mobility of terminals/users/applications?
A lot of today's terminals are mobile, e.g. laptops and smartphones. When
 they move should their in-network storage move with them or should access
 to their storage be made by tunneling back to some type of "home storage"?
    
I think this is a good discussion to have and it would be great to get 
opinions from others. My personal feeling is to leave automatic data migration 
out of scope, since it may make the system quite complicated. In particular, 
one of the things we explicitly mentioned as out-of-scope was finding the 
"best" in-network storage element. I think that what you mention here for 
mobility is somewhat related to this.
If we don't want to get into data migration and trying to find 'the best' copy I would settle to for agreeing that it is ok to use locally available copies if they happens to be around. As I indicated above this could simplify giving some basic support for nodes that are not permanently stationary in the network.
Finally a formulation I find confusing.
In §5 it states:
"The Working Group (WG) will design and specify a standard protocol for P2P
applications to utilize in-network storage."
Then in the last bullet of out-of-scope issues it states:
"Developing a new protocol to deliver content between P2P application and
  in-network storage."
A new proposal for this statement is:
"Developing a new protocol for data transport between P2P applications and
  in-network storage."
I think both these alternatives can easily be seen as contradicting the
 initial statement.
    
 As I understand it, what is out of scope are protocols
 between two p2p applications, e.g. BitTorrent like protocols,
    
Yes - this is out-of-scope.
  
 as well as
 protocols between two instances of in-network storage, e.g. for cache
 migration.
    
The protocol between two in-network storage instances is not currently out-of-
scope.  One case where such a protocol can be useful in P2P is when both the 
uploading and downloading user have in-network storage. See section 5.3.1 of 
the current draft of the problem statement for an example:
  http://tools.ietf.org/html/draft-song-decade-problem-statement-00

In the eventual specification, the actual data transport between two in-
network storages may be done by the underlying protocol, but we may also need 
to pass access control / resource control between them as well (which would be 
in scope for DECADE).

  
 But protocols for data transport between a p2p application and
 an in-network storage is very much *in* scope.
    

The idea is that we'd like to be able to use existing storage access protocols 
where possible.  The candidates that we mention in the charter currently are 
NFS and WebDAV.  However, in DECADE, we need to pass some additional 
information between the user and in-network storage (e.g., resource control 
and access control).  Do you have suggestions for an alternate wording here?
If the current thinking is that we want to try to find a suitable protocol to be reused I think it is a bit premature to state that developing a new protocol is out of scope before we have even defined the requirements for the functionality of the new protocol.

    Börje


--------------040708020507040100020109-- From melodysong@huawei.com Fri Jan 29 17:35:07 2010 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 17B293A635F for ; Fri, 29 Jan 2010 17:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voMgLvl8O4ta for ; Fri, 29 Jan 2010 17:35:05 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 37A803A680A for ; Fri, 29 Jan 2010 17:35:05 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KX10079MDQUTK@szxga03-in.huawei.com> for decade@ietf.org; Sat, 30 Jan 2010 09:35:19 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KX100CB7DQUX7@szxga03-in.huawei.com> for decade@ietf.org; Sat, 30 Jan 2010 09:35:18 +0800 (CST) Received: from s64081a ([10.164.12.49]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KX1003CMDQRAX@szxml06-in.huawei.com> for decade@ietf.org; Sat, 30 Jan 2010 09:35:18 +0800 (CST) Date: Sat, 30 Jan 2010 09:35:15 +0800 From: Song Haibin In-reply-to: To: "'Strandberg, Ove (NSN - FI/Espoo)'" , 'ext Enrico Marocco' , 'Richard Alimi' Message-id: <006d01caa14c$79419cd0$310ca40a@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: AcqfN8VsiuqE2r8KQ0qgOs229v+PcAAANeEgAFUN20AAEAtPcAAfn2zA Cc: decade@ietf.org Subject: Re: [decade] Updated DECADE Charter 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, 30 Jan 2010 01:35:07 -0000 I would like to hear other people's opinions. My personal feeling is that it will get things a little complicated. You have to do a survey of resource/access control behaviors for other types of applications which will possibly use in-network storage, that will broaden the scope a lot. Xie Xie, Haibin > -----Original Message----- > From: Strandberg, Ove (NSN - FI/Espoo) > [mailto:ove.strandberg@nsn.com] > Sent: Friday, January 29, 2010 6:41 PM > To: ext Song Haibin; ext Enrico Marocco; Richard Alimi > Cc: decade@ietf.org > Subject: RE: [decade] Updated DECADE Charter > > Hi Haibin, > > Thanks for your comments. > > My main concern with P2P as use case is that other > interaction towards a network storage other than originating > from a P2P client will not be considered. I could easily > imagine the benefit of network storage for examples for > applications like Spotify, Youtube, IPTV etc.. They can > potentially be interedsted in memory utilization too. Thus > there are other potential use of a network storage protocol. > The relationship of these towards a network storage looks > different from a P2P client perspective and designing from > only P2P in first step potentially limiting. > > This use case concern is of principal matter (me thinks) and > the charter should reflect this already now. This change does > not change the fact that most interest might be on solving > the P2P use case, but there are more use cases that should be > included in the charter description. > > Br, > > +Ove > > >-----Original Message----- > >From: ext Song Haibin [mailto:melodysong@huawei.com] > >Sent: 29 January, 2010 04:56 > >To: Strandberg, Ove (NSN - FI/Espoo); 'ext Enrico Marocco'; 'Richard > >Alimi' > >Cc: decade@ietf.org > >Subject: RE: [decade] Updated DECADE Charter > > > > > >Hi Ove, > > > >Thanks for the good comment. It is very useful if the > protocol can be > >used by other types of applications. But If you consider other > >applications for the first step, you have to incorporate other > >features. For example, you may need replicas in the > in-network storage > >to guarantee QoS. I prefer to focus on P2P applications > initially, but > >keep other applications in mind, so that later extensions > can be made > >to let better integration with other applications. > > > >Xie Xie, > >Haibin > > > > > >> -----Original Message----- > >> From: decade-bounces@ietf.org > >> [mailto:decade-bounces@ietf.org] On Behalf Of Strandberg, > Ove (NSN - > >> FI/Espoo) > >> Sent: Wednesday, January 27, 2010 6:13 PM > >> To: ext Enrico Marocco; Richard Alimi > >> Cc: decade@ietf.org > >> Subject: Re: [decade] Updated DECADE Charter > >> > >> Hi all, > >> > >> At the pre-BOF in Stockholm also other applications than P2P was > >> discussed. I probably missed some of the discussion in > >Hiroshima, but > >> I would appriciate shifting focus from P2P intpo more > generic use of > >> network storage, eg. We should not get into too P2P specific > >solution. > >> The statement: > >> > >> "The protocol will be focused on P2P applications, though it > >may also > >> be used in other types of applications." > >> > >> Could be reworked: > >> > >> "The protocol will be focused on P2P applications, though it > >should be > >> generic to allow usage in other types of applications also." > >> > >> Br, > >> > >> +Ove > >> > >> Ps. I also have background in Network of Information in > >4WARD project. > >> Ds. > >> > >> >-----Original Message----- > >> >From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On > >> >Behalf Of ext Enrico Marocco > >> >Sent: 27 January, 2010 12:02 > >> >To: Richard Alimi > >> >Cc: decade@ietf.org > >> >Subject: Re: [decade] Updated DECADE Charter > >> > > >> >Thanks for putting this together! > >> > > >> >In general I like text, but one thing I think we should do very > >> >carefully is to precisely list what we are sure is missing from > >> >existing protocols -- fine grained access and resource > >> control, right? > >> >-- as, at the end of the day, that will be the reason why > >> the IESG may > >> >decide to charter a new WG. To this extent, I'd prefer to be more > >> >explicit, at the risk of being redundant, e.g. in the last > >> sentence of > >> >paragraph 3: > >> > > >> > Though there are existing data access protocols (e.g., > HTTP, NFS, > >> > WebDAV), they lack capabilities needed when applied in > >this context. > >> > > >> >What about replacing it with something along this line? > >> > > >> > Though there are existing data access protocols (e.g., > HTTP, NFS, > >> > WebDAV), they lack capabilities for fine-grained access and > >> resource > >> > control that are essential for today's advanced P2P algorithms. > >> > > >> >Enrico > >> > > >> >Richard Alimi wrote: > >> >> Hi All, > >> >> > >> >> We have been working on a new charter with a refined scope and > >> >> incorporating past discussion on the mailing list. It would be > >> >> wonderful to hear comments on the new proposed charter. > >> >> > >> >> > >> >============================================================= > >> ========= > >> >> == > >> >> > >> >> DECoupled Application Data Enroute > >> >> > >> >> Description of Working Group: > >> >> > >> >> Peer-to-Peer (P2P) applications, including both P2P > >> >streaming and P2P > >> >> file- sharing applications, make up a large fraction of > >> >traffic in the > >> >> Internet today. One way to reduce access network and/or > >> cross-domain > >> >> bandwidth usage by P2P applications is to introduce storage > >> >capabilities in the networks. > >> >> Allowing P2P applications to store and retrieve data > from inside > >> >> networks can reduce traffic on the last-mile uplink, as well > >> >as backbone and transit links. > >> >> > >> >> Existing P2P caches often implement the specific P2P > application > >> >> protocols to operate transparently or act as super peers to > >> >provide in-network storage. > >> >> However, this approach poses challenges to both P2P cache > >> >vendors and > >> >> P2P application developers. For P2P cache vendors, the > >> >challenge is to > >> >> support a variety of exisiting and evolving protocols. For P2P > >> >> applications, closed P2P caching systems limit effective > >> utilization > >> >> of in-network storage. Some P2P protocols may be entirely > >> >unsupported, > >> >> and applications may be better-equipped to decide how > in-network > >> >> storage is used to meet their specific requirements (e.g., > >> >data placement, access control and resource control). > >> >> > >> >> Both of these challenges can be effectively addressed > by using an > >> >> open, standard protocol to access in-network storage. P2P > >> >applications > >> >> can store and retrieve content in the in-network storage, > >> as well as > >> >> control resources (e.g., bandwidth, connections) consumed by > >> >peers in > >> >> a P2P application. As a simple example, a peer can choose > >> to store > >> >> content in the in-network storage, and direct other peers to > >> >retrieve > >> >> from that location, reducing last-mile link usage. Though > >> there are > >> >> existing data access protocols (e.g., HTTP, NFS, WebDAV), > >> >they lack capabilities needed when applied in this context. > >> >> > >> >> The Working Group (WG) will design and specify a standard > >> >protocol for > >> >> P2P applications to utilize in-network storage. The > >protocol will > >> >> include operations for a P2P application to (1) store, > >> retrieve, and > >> >> manage data, (2) specify access control for storing and > >retrieving > >> >> data suitable for a P2P environment with peers across multiple > >> >> administrative and security domains, and (3) indicate > >> >resource control policies for storing and retrieving data. > >> >> The WG will leverage existing IETF protocols where possible, in > >> >> particular for storing, retrieving, and managing data. > >> >> > >> >> This WG will focus mainly on the protocol between the > in-network > >> >> storage and P2P applications. The protocol will be > >focused on P2P > >> >> applications, though it may also be used in other types of > >> >applications. > >> >> > >> >> The WG will focus on the following work items: > >> >> > >> >> - A "problem statement" document. This document provides a > >> >description of the > >> >> problem and common terminology. > >> >> > >> >> - A requirements document. This document lists the > >> >requirements for the > >> >> in-network storage service (e.g., supported operations) > >> >and the protocol to > >> >> support it. > >> >> > >> >> - A survey document. This document will survey existing > >> >related mechanisms > >> >> and protocols (e.g., HTTP, NFS, and WebDAV), and > evaluate their > >> >> applicability and effectiveness. > >> >> > >> >> - A signaling protocol for storing, retrieving, and managing > >> >data as well as > >> >> specifying both access control and resource control > >> policies in the > >> >> in-network storage pertaining to that data. Data storage, > >> >retrieval, and > >> >> management may be provided by an existing IETF protocol. > >> >If the underlying > >> >> protocol does not support certain data management > >> >operations, DECADE may > >> >> seek to define such extensions and present them to the > >> >respective working > >> >> groups or create an Individual Submission if no active > >> >working group exists. > >> >> This group may also create a profile of necessary > >> >operations from an > >> >> existing IETF protocol to reduce the complexity and > >> >software footprint of a > >> >> compliant implementation. > >> >> > >> >> The WG will not limit itself to a single underlying > >> >protocol since different > >> >> underlying protocols may have varying implementation costs > >> >and performance > >> >> tradeoffs. To keep interoperability manageable, a small > >> >number of specific, > >> >> targeted, underlying protocols will be used. NFS and > >> >WebDAV are initial > >> >> targets and others may be incorporated with WG consensus. > >> >> > >> >> - An informational document describing the integration of > >> >DECADE with existing > >> >> P2P applications (e.g., integration with BitTorrent). > >> >> > >> >> The following issues are not considered in the current scope > >> >of the WG: > >> >> > >> >> - Copyright protected or illegal content > >> >> For example, one possibility is that that an in-network > >> >storage system may > >> >> have system-wide ingress and egress filters to implement > >> >policies related to > >> >> copyrighted and illegal content. This is outside the > >> >scope of this working > >> >> group. > >> >> > >> >> - Locating the "best" in-network storage location from which > >> >to retrieve > >> >> content if there are more than one location can provide > >> >the same content. > >> >> > >> >> - Developing a new protocol to deliver content between P2P > >> >application and > >> >> in-network storage. > >> >> > >> >> Goals and Milestones: > >> >> > >> >> May 2010 Working Group Last Call for problem statement > Aug 2010 > >> >> Submit problem statement to IESG as Informational Aug 2010 > >> Working > >> >> Group Last Call for requirements document Feb 2011 Submit > >> >> requirements document to IESG as Informational May 2011 > >> >Working Group > >> >> Last Call for survey document Aug 2011 Working Group Last > >> Call for > >> >> in-network storage access protocol Aug 2011 Submit survey > >> >document to > >> >> IESG as Informational Nov 2011 Submit in-network > storage access > >> >> protocol to IESG as Proposed > >> >> Standard > >> >> > >> >> > >> >============================================================= > >> ========= > >> >> == > >> >> > >> >> Thanks! > >> > > >> _______________________________________________ > >> decade mailing list > >> decade@ietf.org > >> https://www.ietf.org/mailman/listinfo/decade > >> > > > > > > > From wleggette@cleversafe.com Fri Jan 29 17:35:59 2010 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 672313A67D7 for ; Fri, 29 Jan 2010 17:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 DmNgOZoy99Ar for ; Fri, 29 Jan 2010 17:35:57 -0800 (PST) Received: from p01c11o145.mxlogic.net (p01c11o145.mxlogic.net [208.65.144.68]) by core3.amsl.com (Postfix) with ESMTP id 4E6873A635F for ; Fri, 29 Jan 2010 17:35:57 -0800 (PST) Received: from unknown [216.166.12.69] (EHLO p01c11o145.mxlogic.net) by p01c11o145.mxlogic.net(mxl_mta-6.5.0-0) with ESMTP id 51d836b4.c5cddb90.19132.00-406.40884.p01c11o145.mxlogic.net (envelope-from ); Fri, 29 Jan 2010 18:36:21 -0700 (MST) X-MXL-Hash: 4b638d154170ea84-9b6076e0e5bff98be1960fe2d7e246e1147f63ba Received: from unknown [216.166.12.69] (EHLO out001.collaborationhost.net) by p01c11o145.mxlogic.net(mxl_mta-6.5.0-0) over TLS secured channel with ESMTP id 9fc836b4.0.19097.00-005.40826.p01c11o145.mxlogic.net (envelope-from ); Fri, 29 Jan 2010 18:36:03 -0700 (MST) X-MXL-Hash: 4b638d0344f7664a-7507b7d9047dd82ab5e6ceed81a8ab3bbeb27439 Received: from AUSP01VMBX09.collaborationhost.net ([10.2.8.161]) by AUSP01MHUB03.collaborationhost.net ([10.2.8.78]) with mapi; Fri, 29 Jan 2010 19:35:53 -0600 From: Wesley Leggette To: "Y.J. Gu" , "Strandberg, Ove (NSN - FI/Espoo)" , ext Song Haibin , ext Enrico Marocco , Richard Alimi Date: Fri, 29 Jan 2010 19:35:52 -0600 Thread-Topic: [decade] Updated DECADE Charter Thread-Index: AcqfN8VsiuqE2r8KQ0qgOs229v+PcAAANeEgAFUN20AAEAtPcAADUK3gABySWME= Message-ID: In-Reply-To: <00d301caa0db$e164c4c0$400ca40a@china.huawei.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010011101)] X-MAIL-FROM: X-SOURCE-IP: [216.166.12.69] X-AnalysisOut: [v=1.0 c=1 a=TYbMNos9eHUa9bm6/o8foQ==:17 a=i0EeH86SAAAA:8 a] X-AnalysisOut: [=48vgC7mUAAAA:8 a=Z7rXUxud1qGuwn4ZSesA:9 a=xediMXCD611FsKO] X-AnalysisOut: [uy_wA:7 a=h2VdlrFZ7aOOMIf4NiEqmLEWkvQA:4 a=hPjdaMEvmhQA:10] X-AnalysisOut: [ a=lZB815dzVvQA:10 a=QazLzJ4oOTpb_wEK:21 a=wzWLMLj-JZinWt-] X-AnalysisOut: [C:21] Cc: DECADE Subject: Re: [decade] Updated DECADE Charter 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, 30 Jan 2010 01:35:59 -0000 As I've said before, I'm also interested in a more general purpose distributed network storage protocol. Specifically, it would be nice to hav= e a standards-based protocol with at least the primitives necessary to suppor= t a distributed file system. These would include at the very least proper revision/commit safeties and support for some form of distributed write locking. As for analyzing whether compatibility with other applications makes sense for DECADE, I know off hand of quite a few differences which could make it difficult to merge DECADE's original goal with a more general storage network protocol. The main difference is in the way the presence of data is communicated. P2P is generally geared towards out-of-band advertising and in-band pull (the download from the peer) and replicate (when the data is cached locally on the requesting client). With a storage system, clients expect to be able to push data, and this presents timing problems when it comes time to advertis= e what data was just written. How do other users know if data has been written? Is it advertised out-of-band after the entire data set is written? This is an approach similar to BitTorrent where you have to obtain torrent files somehow after the first seed is complete. Is there an in-band mechanism to list or query what is out there in a generic way? If so, when is data visible in the in-band mechanism; during a write or after all write= s are complete? Also, if the goal is for "other applications", are these write-once-read-many systems, or can data be overwritten? If the system is designed to allow data to be overwritten then there has to be a mechanism t= o safely update multi-part data (so that a large file can be stored in smalle= r segments and the correct matching segment versions are always available). If DECADE ends up being just a way to cache data requests made through a particular P2P system, it's also worth noting that different P2P systems us= e different data formats. If DECADE just provides format unaware storage this could mean that data will have to be stored twice if its made available ove= r different P2P applications. While I'm not sure that DECADE wants to deal with any of these issues, it could very well be worth creating a second working group to deal with general purpose distributed storage system. Wesley Leggette On 1/29/10 04:09, "Y.J. Gu" wrote: > Hi, > I agree with taking other applications into consideration at the first > beginning. At least we should analyze whether compatible with other > applications will make significant difference, comparing with the > protocol/mechanism designed exclusively for P2P. > If we donot want to make this effort, then how about just removing words > like "can be used by other applications". > > My 2 cents. > > Regards > Yingjie Gu > > > >> -----Original Message----- >> From: decade-bounces@ietf.org >> [mailto:decade-bounces@ietf.org] On Behalf Of Strandberg, Ove >> (NSN - FI/Espoo) >> Sent: Friday, January 29, 2010 6:41 PM >> To: ext Song Haibin; ext Enrico Marocco; Richard Alimi >> Cc: decade@ietf.org >> Subject: Re: [decade] Updated DECADE Charter >> >> Hi Haibin, >> >> Thanks for your comments. >> >> My main concern with P2P as use case is that other >> interaction towards a network storage other than originating >> from a P2P client will not be considered. I could easily >> imagine the benefit of network storage for examples for >> applications like Spotify, Youtube, IPTV etc.. They can >> potentially be interedsted in memory utilization too. Thus >> there are other potential use of a network storage protocol. >> The relationship of these towards a network storage looks >> different from a P2P client perspective and designing from >> only P2P in first step potentially limiting. >> >> This use case concern is of principal matter (me thinks) and >> the charter should reflect this already now. This change does >> not change the fact that most interest might be on solving >> the P2P use case, but there are more use cases that should be >> included in the charter description. >> >> Br, >> >> +Ove >> >>> -----Original Message----- >>> From: ext Song Haibin [mailto:melodysong@huawei.com] >>> Sent: 29 January, 2010 04:56 >>> To: Strandberg, Ove (NSN - FI/Espoo); 'ext Enrico Marocco'; 'Richard >>> Alimi' >>> Cc: decade@ietf.org >>> Subject: RE: [decade] Updated DECADE Charter >>> >>> >>> Hi Ove, >>> >>> Thanks for the good comment. It is very useful if the >> protocol can be >>> used by other types of applications. But If you consider other >>> applications for the first step, you have to incorporate other >>> features. For example, you may need replicas in the >> in-network storage >>> to guarantee QoS. I prefer to focus on P2P applications >> initially, but >>> keep other applications in mind, so that later extensions >> can be made >>> to let better integration with other applications. >>> >>> Xie Xie, >>> Haibin >>> >>> >>>> -----Original Message----- >>>> From: decade-bounces@ietf.org >>>> [mailto:decade-bounces@ietf.org] On Behalf Of Strandberg, >> Ove (NSN - >>>> FI/Espoo) >>>> Sent: Wednesday, January 27, 2010 6:13 PM >>>> To: ext Enrico Marocco; Richard Alimi >>>> Cc: decade@ietf.org >>>> Subject: Re: [decade] Updated DECADE Charter >>>> >>>> Hi all, >>>> >>>> At the pre-BOF in Stockholm also other applications than P2P was >>>> discussed. I probably missed some of the discussion in >>> Hiroshima, but >>>> I would appriciate shifting focus from P2P intpo more >> generic use of >>>> network storage, eg. We should not get into too P2P specific >>> solution. >>>> The statement: >>>> >>>> "The protocol will be focused on P2P applications, though it >>> may also >>>> be used in other types of applications." >>>> >>>> Could be reworked: >>>> >>>> "The protocol will be focused on P2P applications, though it >>> should be >>>> generic to allow usage in other types of applications also." >>>> >>>> Br, >>>> >>>> +Ove >>>> >>>> Ps. I also have background in Network of Information in >>> 4WARD project. >>>> Ds. >>>> >>>>> -----Original Message----- >>>>> From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On >>>>> Behalf Of ext Enrico Marocco >>>>> Sent: 27 January, 2010 12:02 >>>>> To: Richard Alimi >>>>> Cc: decade@ietf.org >>>>> Subject: Re: [decade] Updated DECADE Charter >>>>> >>>>> Thanks for putting this together! >>>>> >>>>> In general I like text, but one thing I think we should do very >>>>> carefully is to precisely list what we are sure is missing from >>>>> existing protocols -- fine grained access and resource >>>> control, right? >>>>> -- as, at the end of the day, that will be the reason why >>>> the IESG may >>>>> decide to charter a new WG. To this extent, I'd prefer to be more >>>>> explicit, at the risk of being redundant, e.g. in the last >>>> sentence of >>>>> paragraph 3: >>>>> >>>>> Though there are existing data access protocols (e.g., >> HTTP, NFS, >>>>> WebDAV), they lack capabilities needed when applied in >>> this context. >>>>> >>>>> What about replacing it with something along this line? >>>>> >>>>> Though there are existing data access protocols (e.g., >> HTTP, NFS, >>>>> WebDAV), they lack capabilities for fine-grained access and >>>> resource >>>>> control that are essential for today's advanced P2P algorithms. >>>>> >>>>> Enrico >>>>> >>>>> Richard Alimi wrote: >>>>>> Hi All, >>>>>> >>>>>> We have been working on a new charter with a refined scope and >>>>>> incorporating past discussion on the mailing list. It would be >>>>>> wonderful to hear comments on the new proposed charter. >>>>>> >>>>>> >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>> =3D=3D >>>>>> >>>>>> DECoupled Application Data Enroute >>>>>> >>>>>> Description of Working Group: >>>>>> >>>>>> Peer-to-Peer (P2P) applications, including both P2P >>>>> streaming and P2P >>>>>> file- sharing applications, make up a large fraction of >>>>> traffic in the >>>>>> Internet today. One way to reduce access network and/or >>>> cross-domain >>>>>> bandwidth usage by P2P applications is to introduce storage >>>>> capabilities in the networks. >>>>>> Allowing P2P applications to store and retrieve data >> from inside >>>>>> networks can reduce traffic on the last-mile uplink, as well >>>>> as backbone and transit links. >>>>>> >>>>>> Existing P2P caches often implement the specific P2P >> application >>>>>> protocols to operate transparently or act as super peers to >>>>> provide in-network storage. >>>>>> However, this approach poses challenges to both P2P cache >>>>> vendors and >>>>>> P2P application developers. For P2P cache vendors, the >>>>> challenge is to >>>>>> support a variety of exisiting and evolving protocols. For P2P >>>>>> applications, closed P2P caching systems limit effective >>>> utilization >>>>>> of in-network storage. Some P2P protocols may be entirely >>>>> unsupported, >>>>>> and applications may be better-equipped to decide how >> in-network >>>>>> storage is used to meet their specific requirements (e.g., >>>>> data placement, access control and resource control). >>>>>> >>>>>> Both of these challenges can be effectively addressed >> by using an >>>>>> open, standard protocol to access in-network storage. P2P >>>>> applications >>>>>> can store and retrieve content in the in-network storage, >>>> as well as >>>>>> control resources (e.g., bandwidth, connections) consumed by >>>>> peers in >>>>>> a P2P application. As a simple example, a peer can choose >>>> to store >>>>>> content in the in-network storage, and direct other peers to >>>>> retrieve >>>>>> from that location, reducing last-mile link usage. Though >>>> there are >>>>>> existing data access protocols (e.g., HTTP, NFS, WebDAV), >>>>> they lack capabilities needed when applied in this context. >>>>>> >>>>>> The Working Group (WG) will design and specify a standard >>>>> protocol for >>>>>> P2P applications to utilize in-network storage. The >>> protocol will >>>>>> include operations for a P2P application to (1) store, >>>> retrieve, and >>>>>> manage data, (2) specify access control for storing and >>> retrieving >>>>>> data suitable for a P2P environment with peers across multiple >>>>>> administrative and security domains, and (3) indicate >>>>> resource control policies for storing and retrieving data. >>>>>> The WG will leverage existing IETF protocols where possible, in >>>>>> particular for storing, retrieving, and managing data. >>>>>> >>>>>> This WG will focus mainly on the protocol between the >> in-network >>>>>> storage and P2P applications. The protocol will be >>> focused on P2P >>>>>> applications, though it may also be used in other types of >>>>> applications. >>>>>> >>>>>> The WG will focus on the following work items: >>>>>> >>>>>> - A "problem statement" document. This document provides a >>>>> description of the >>>>>> problem and common terminology. >>>>>> >>>>>> - A requirements document. This document lists the >>>>> requirements for the >>>>>> in-network storage service (e.g., supported operations) >>>>> and the protocol to >>>>>> support it. >>>>>> >>>>>> - A survey document. This document will survey existing >>>>> related mechanisms >>>>>> and protocols (e.g., HTTP, NFS, and WebDAV), and >> evaluate their >>>>>> applicability and effectiveness. >>>>>> >>>>>> - A signaling protocol for storing, retrieving, and managing >>>>> data as well as >>>>>> specifying both access control and resource control >>>> policies in the >>>>>> in-network storage pertaining to that data. Data storage, >>>>> retrieval, and >>>>>> management may be provided by an existing IETF protocol. >>>>> If the underlying >>>>>> protocol does not support certain data management >>>>> operations, DECADE may >>>>>> seek to define such extensions and present them to the >>>>> respective working >>>>>> groups or create an Individual Submission if no active >>>>> working group exists. >>>>>> This group may also create a profile of necessary >>>>> operations from an >>>>>> existing IETF protocol to reduce the complexity and >>>>> software footprint of a >>>>>> compliant implementation. >>>>>> >>>>>> The WG will not limit itself to a single underlying >>>>> protocol since different >>>>>> underlying protocols may have varying implementation costs >>>>> and performance >>>>>> tradeoffs. To keep interoperability manageable, a small >>>>> number of specific, >>>>>> targeted, underlying protocols will be used. NFS and >>>>> WebDAV are initial >>>>>> targets and others may be incorporated with WG consensus. >>>>>> >>>>>> - An informational document describing the integration of >>>>> DECADE with existing >>>>>> P2P applications (e.g., integration with BitTorrent). >>>>>> >>>>>> The following issues are not considered in the current scope >>>>> of the WG: >>>>>> >>>>>> - Copyright protected or illegal content >>>>>> For example, one possibility is that that an in-network >>>>> storage system may >>>>>> have system-wide ingress and egress filters to implement >>>>> policies related to >>>>>> copyrighted and illegal content. This is outside the >>>>> scope of this working >>>>>> group. >>>>>> >>>>>> - Locating the "best" in-network storage location from which >>>>> to retrieve >>>>>> content if there are more than one location can provide >>>>> the same content. >>>>>> >>>>>> - Developing a new protocol to deliver content between P2P >>>>> application and >>>>>> in-network storage. >>>>>> >>>>>> Goals and Milestones: >>>>>> >>>>>> May 2010 Working Group Last Call for problem statement >> Aug 2010 >>>>>> Submit problem statement to IESG as Informational Aug 2010 >>>> Working >>>>>> Group Last Call for requirements document Feb 2011 Submit >>>>>> requirements document to IESG as Informational May 2011 >>>>> Working Group >>>>>> Last Call for survey document Aug 2011 Working Group Last >>>> Call for >>>>>> in-network storage access protocol Aug 2011 Submit survey >>>>> document to >>>>>> IESG as Informational Nov 2011 Submit in-network >> storage access >>>>>> protocol to IESG as Proposed >>>>>> Standard >>>>>> >>>>>> >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>> =3D=3D >>>>>> >>>>>> Thanks! >>>>> >>>> _______________________________________________ >>>> 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 Jan 29 19:07:11 2010 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 778FA28C0F1 for ; Fri, 29 Jan 2010 19:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.053 X-Spam-Level: X-Spam-Status: No, score=-0.053 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, 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 2bBalDBfWqLq for ; Fri, 29 Jan 2010 19:07:10 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id BB4513A690D for ; Fri, 29 Jan 2010 19:07:09 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KX1004HRI0BD1@szxga03-in.huawei.com> for decade@ietf.org; Sat, 30 Jan 2010 11:07:23 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KX100A1LI0BRZ@szxga03-in.huawei.com> for decade@ietf.org; Sat, 30 Jan 2010 11:07:23 +0800 (CST) Received: from s64081a ([10.164.12.49]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KX1004NOI07WW@szxml06-in.huawei.com> for decade@ietf.org; Sat, 30 Jan 2010 11:07:23 +0800 (CST) Date: Sat, 30 Jan 2010 11:07:18 +0800 From: Song Haibin In-reply-to: <8A82D1BFEDDE7E4597978355239BBBCBB58DC3@PACDCEXCMB06.cable.comcast.com> To: "'Woundy, Richard'" , decade@ietf.org Message-id: <007601caa159$55ca8f20$310ca40a@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_y9xTN7lpSiT5Mq1oBSMXqA)" Thread-index: AcqbwWbk4XLuXW2hR9q/qD9jkxsqsQFl1HmA Subject: Re: [decade] RFC series for NFS v4.1 just published 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, 30 Jan 2010 03:07:11 -0000 This is a multi-part message in MIME format. --Boundary_(ID_y9xTN7lpSiT5Mq1oBSMXqA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I got the following information through the reference.. http://en.wikipedia.org/wiki/Network_File_System_(protocol SMB and NetWare Core Protocol (NCP) occur more commonly than NFS on systems running Microsoft Windows; AFP occurs more commonly than NFS in Macintosh systems; and QFileSvr.400 occurs more commonly in AS/400 systems. Xie Xie, Haibin _____ From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Woundy, Richard Sent: Saturday, January 23, 2010 8:17 AM To: decade@ietf.org Subject: [decade] RFC series for NFS v4.1 just published Folks, Since we are seriously looking at NFS as a candidate data access and management protocol for Decade, we should all be aware of the latest NFS v4.1 RFCs published by the nfsv4 working group just this week: 5661 Network File System (NFS) Version 4 Minor Version 1 Protocol S. Shepler, M. Eisler, D. Noveck [ January 2010 ] (TXT = 1517771) (Status: PROPOSED STANDARD) (Stream: IETF, Area: tsv, WG: nfsv4) 5662 Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description S. Shepler, M. Eisler, D. Noveck [ January 2010 ] (TXT = 126581) (Status: PROPOSED STANDARD) (Stream: IETF, Area: tsv, WG: nfsv4) 5663 Parallel NFS (pNFS) Block/Volume Layout D. Black, S. Fridella, J. Glasgow [ January 2010 ] (TXT = 68571) (Status: PROPOSED STANDARD) (Stream: IETF, Area: tsv, WG: nfsv4) 5664 Object-Based Parallel NFS (pNFS) Operations B. Halevy, B. Welch, J. Zelenka [ January 2010 ] (TXT = 78200) (Status: PROPOSED STANDARD) (Stream: IETF, Area: tsv, WG: nfsv4) 5665 IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats M. Eisler [ January 2010 ] (TXT = 28706) (Updates RFC1833 ) (Status: PROPOSED STANDARD) (Stream: IETF, Area: tsv, WG: nfsv4) 5666 Remote Direct Memory Access Transport for Remote Procedure Call T. Talpey, B. Callaghan [ January 2010 ] (TXT = 83728) (Status: PROPOSED STANDARD) (Stream: IETF, Area: tsv, WG: nfsv4) 5667 Network File System (NFS) Direct Data Placement T. Talpey, B. Callaghan [ January 2010 ] (TXT = 83728) (Status: PROPOSED STANDARD) (Stream: IETF, Area: tsv, WG: nfsv4) -- Rich --Boundary_(ID_y9xTN7lpSiT5Mq1oBSMXqA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
I got the following information through the reference..
 
 
SMB and NetWare Core Protocol (NCP) occur more commonly than NFS on systems running Microsoft Windows; AFP occurs more commonly than NFS in Macintosh systems; and QFileSvr.400 occurs more commonly in AS/400 systems.
 
Xie Xie,
Haibin
 

From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Woundy, Richard
Sent: Saturday, January 23, 2010 8:17 AM
To: decade@ietf.org
Subject: [decade] RFC series for NFS v4.1 just published

Folks,

 

Since we are seriously looking at NFS as a candidate data access and management protocol for Decade, we should all be aware of the latest NFS v4.1 RFCs published by the nfsv4 working group just this week:

 

5661

Network File System (NFS) Version 4 Minor Version 1 Protocol S. Shepler, M. Eisler, D. Noveck [ January 2010 ] (TXT = 1517771) (Status: PROPOSED STANDARD) (Stream: IETF, Area: tsv, WG: nfsv4)

5662

Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description S. Shepler, M. Eisler, D. Noveck [ January 2010 ] (TXT = 126581) (Status: PROPOSED STANDARD) (Stream: IETF, Area: tsv, WG: nfsv4)

5663

Parallel NFS (pNFS) Block/Volume Layout D. Black, S. Fridella, J. Glasgow [ January 2010 ] (TXT = 68571) (Status: PROPOSED STANDARD) (Stream: IETF, Area: tsv, WG: nfsv4)

5664

Object-Based Parallel NFS (pNFS) Operations B. Halevy, B. Welch, J. Zelenka [ January 2010 ] (TXT = 78200) (Status: PROPOSED STANDARD) (Stream: IETF, Area: tsv, WG: nfsv4)

5665

IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats M. Eisler [ January 2010 ] (TXT = 28706) (Updates RFC1833) (Status: PROPOSED STANDARD) (Stream: IETF, Area: tsv, WG: nfsv4)

5666

Remote Direct Memory Access Transport for Remote Procedure Call T. Talpey, B. Callaghan [ January 2010 ] (TXT = 83728) (Status: PROPOSED STANDARD) (Stream: IETF, Area: tsv, WG: nfsv4)

5667

Network File System (NFS) Direct Data Placement T. Talpey, B. Callaghan [ January 2010 ] (TXT = 83728) (Status: PROPOSED STANDARD) (Stream: IETF, Area: tsv, WG: nfsv4)

 

-- Rich

--Boundary_(ID_y9xTN7lpSiT5Mq1oBSMXqA)-- From richard.alimi@yale.edu Sun Jan 31 20:25:05 2010 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 E0CE63A6859 for ; Sun, 31 Jan 2010 20:25:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=-0.925, 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 oAxzVuTFPHE3 for ; Sun, 31 Jan 2010 20:25:05 -0800 (PST) Received: from pantheon-po34.its.yale.edu (pantheon-po34.its.yale.edu [130.132.50.80]) by core3.amsl.com (Postfix) with ESMTP id A96C73A6840 for ; Sun, 31 Jan 2010 20:25:04 -0800 (PST) Received: from poweredge.velvetsea.net (adsl-69-183-236-39.dsl.wlfrct.sbcglobal.net [69.183.236.39]) (authenticated bits=0) by pantheon-po34.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id o114PPpw024227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 31 Jan 2010 23:25:33 -0500 Received: from laptop.localnet (unknown [192.168.1.78]) by poweredge.velvetsea.net (Postfix) with ESMTPSA id 8A3EF42401C; Sun, 31 Jan 2010 23:25:25 -0500 (EST) From: Richard Alimi To: Lars Eggert Date: Sun, 31 Jan 2010 23:25:24 -0500 User-Agent: KMail/1.12.4 (Linux/2.6.31-gentoo-r6; KDE/4.3.4; x86_64; ; ) References: <201001221658.24381.richard.alimi@yale.edu> <201001270919.18847.richard.alimi@yale.edu> <96A9D5A9-A584-4905-AD5F-58EC1A588E3E@nokia.com> In-Reply-To: <96A9D5A9-A584-4905-AD5F-58EC1A588E3E@nokia.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201001312325.24411.richard.alimi@yale.edu> X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) Cc: "decade@ietf.org" Subject: Re: [decade] Updated DECADE Charter 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, 01 Feb 2010 04:25:06 -0000 Hi Lars, > I'm not the greatest NFS expert in the world either, but IMO the onus is on > the proponents of DECADE to convincingly demonstrate that it would be > better/easier/otherwise useful to create a new protocol here rather than > extending an existing one. Yes, that probably means that someone will have > to familiarize themselves with the existing protocols. Thanks for the response. First, I'd like to clarify that we're on the same page in regards to the intended WG scope. We will indeed re-use existing underlying protocols wherever possible. According to the currently-proposed charter, the new WG would be responsible for: - Defining the access-control requirements, needed resource-control information, and the necessary management interfaces that would be necessary for scenarios where DECADE would be applied (primarily usage by P2P applications). These core pieces would be common to any DECADE implementation. - Define DECADE to operate over existing underlying protocols. In the charter, we have explicitly mentioned NFS and WebDAV as targets, since both are well-established protocols and each may be applicable in different deployment scenarios. For example, when applying to NFS, we will certainly re-use existing mechanisms (e.g., access control if possible, and the hints mechanism) to do so. If the NFS protocol itself would need to be modified or extended, then such modifications or extensions would be presented to the NFSv4 WG. Does the clarify the intended scope? I'm also trying to understand your viewpoint a bit better here. Are you of the opinion that NFS is the only protocol that should be extended? Thanks! -- Richard Alimi Department of Computer Science Yale University From richard.alimi@yale.edu Sun Jan 31 20:55:47 2010 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 878DD3A68B3 for ; Sun, 31 Jan 2010 20:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.066 X-Spam-Level: X-Spam-Status: No, score=-5.066 tagged_above=-999 required=5 tests=[AWL=1.233, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 nOvC1VWVL1Qy for ; Sun, 31 Jan 2010 20:55:46 -0800 (PST) Received: from pantheon-po29.its.yale.edu (pantheon-po29.its.yale.edu [130.132.50.124]) by core3.amsl.com (Postfix) with ESMTP id 5811E3A6853 for ; Sun, 31 Jan 2010 20:55:46 -0800 (PST) Received: from poweredge.velvetsea.net (69-183-236-39.ded.snet.net [69.183.236.39]) (authenticated bits=0) by pantheon-po29.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id o114u9Zq000460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 31 Jan 2010 23:56:10 -0500 Received: from laptop.localnet (unknown [192.168.1.78]) by poweredge.velvetsea.net (Postfix) with ESMTPSA id DEB6842401C; Sun, 31 Jan 2010 23:56:09 -0500 (EST) From: Richard Alimi To: =?iso-8859-15?q?B=F6rje_Ohlman?= Date: Sun, 31 Jan 2010 23:56:08 -0500 User-Agent: KMail/1.12.4 (Linux/2.6.31-gentoo-r6; KDE/4.3.4; x86_64; ; ) References: <201001221658.24381.richard.alimi@yale.edu> <201001270444.47316.richard.alimi@yale.edu> <4B62F41A.6060300@ericsson.com> In-Reply-To: <4B62F41A.6060300@ericsson.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Message-Id: <201001312356.09019.richard.alimi@yale.edu> X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) Cc: decade@ietf.org Subject: Re: [decade] Updated DECADE Charter 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, 01 Feb 2010 04:55:47 -0000 Hi B=F6rje, On Friday 29 January 2010 9:43:38 am B=F6rje Ohlman wrote: > Hi Richard, >=20 > I don't think support for mobility necessarily needs to make things > complex, not if it is designed in from the beginning (e.g. see Internet > Indirection Infrastructure (i3)), it is when it is added as an > afterthought things get complex. That is why I think that support for > basic node mobility should at least be considered. >=20 > I also think the two issues 'copies' and 'mobility' are related to a > certain extent. Being able to use locally available copies rather than > to have to access 'your own' remote or migrated copy can simplify > mobility significantly. Comments below... >=20 > Please see further comments in line below. >=20 > B=F6rje >=20 > Richard Alimi wrote: > > Hi B=F6rje, > > > > Thanks for taking the time to provide feedback. See below: > > > > On Wednesday 27 January 2010 4:01:19 am B=F6rje Ohlman wrote: > >> Hi All, > >> > >> I think this charter starts to look quite good. > >> Though here are two issues I would like to see added to it. > >> > >> 1) How DECADE deals with copies in the in-network storage > >> I think it would be good to make clear if the network part of DECADE c= an > >> benefit when multiple users/application stores the same information > >> object (e.g. file). Is it then possible for DECADE to store only one > >> copy of the information object or is it required to store multiple > >> copies of the same object? > > > > While this is an optimization that could be worthwhile, my feeling is > > that it does not matter with respect to the protocol between the > > application and the storage. If the storage system were to have such a > > feature, it may be an implementation detail. Are you envisioning a case > > where this would surface in the protocol? >=20 > How you refer to an object, e.g. by relative or absolute references, has > an influence on how easy it is to identify a copy of an object. If you > use relative path names to refer to objects see that two objects are the > same. I think I am beginning to see where you are coming from here. My response= =20 above was in the more general case, where the storage system automatically= =20 detected objects that contained exactly the same data, and then, as an=20 optimization in the implementation, deleted one and replaced it with a link= =20 (e.g, a hardlink) to the other. This would have the effect of reducing=20 redundancy across multiple users using storage at the same server. Note th= at=20 it would *not* be safe to only do this based on the naming of the object. However, it sounds like you are referring to a user explicitly creating lin= ks=20 to objects within his or her own storage - is this an accurate=20 characterization? If not, can you provide an example? When it comes to defining exactly which management operations would be=20 supported by DECADE, this is already in the charter. I believe links betw= een=20 objects would be considered a management operation and this would be fair=20 game. You've also touched on the naming here. This is something that would have = to=20 be decided as well within the WG, but is probably not important for the=20 charter. I'd be good to get opinions from others here as well. > >> 2) Should DECADE support mobility of terminals/users/applications? > >> A lot of today's terminals are mobile, e.g. laptops and smartphones. > >> When they move should their in-network storage move with them or should > >> access to their storage be made by tunneling back to some type of "home > >> storage"? > > > > I think this is a good discussion to have and it would be great to get > > opinions from others. My personal feeling is to leave automatic data > > migration out of scope, since it may make the system quite complicated. > > In particular, one of the things we explicitly mentioned as out-of-scope > > was finding the "best" in-network storage element. I think that what you > > mention here for mobility is somewhat related to this. >=20 > If we don't want to get into data migration and trying to find 'the > best' copy I would settle to for agreeing that it is ok to use locally > available copies if they happens to be around. As I indicated above this > could simplify giving some basic support for nodes that are not > permanently stationary in the network. Yes, I certainly agree that it should be possible for clients to use a clos= er=20 copy if it is available. One way I can see for providing such functionalit= y=20 without needing automatic data migration is for a client to locally have a= =20 list of DECADE servers (e.g., DNS names) available to it, and the client=20 locally picks the most-desired one with the data it needs. Are there other possibilities (not using data migration) that you were=20 thinking about? > > The idea is that we'd like to be able to use existing storage access > > protocols where possible. The candidates that we mention in the charter > > currently are NFS and WebDAV. However, in DECADE, we need to pass some > > additional information between the user and in-network storage (e.g., > > resource control and access control). Do you have suggestions for an > > alternate wording here? >=20 > If the current thinking is that we want to try to find a suitable > protocol to be reused I think it is a bit premature to state that > developing a new protocol is out of scope before we have even defined > the requirements for the functionality of the new protocol. We have an initial copy of the requirements draft and have done some initia= l=20 thinking about how it might be applied to NFS or WebDAV. We have also left= =20 the charter open to providing extensions where necessary. Is there certain functionality that you believe would just fundamentally no= t=20 align with such protocols (meaning extensions would not be a good approach)? =2D-=20 Richard Alimi Department of Computer Science Yale University From richard.alimi@yale.edu Sun Jan 31 21:52:37 2010 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 03A233A68F1 for ; Sun, 31 Jan 2010 21:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.524 X-Spam-Level: X-Spam-Status: No, score=-5.524 tagged_above=-999 required=5 tests=[AWL=1.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 22w95rOLL-hb for ; Sun, 31 Jan 2010 21:52:36 -0800 (PST) Received: from pantheon-po29.its.yale.edu (pantheon-po29.its.yale.edu [130.132.50.124]) by core3.amsl.com (Postfix) with ESMTP id BB9B03A659B for ; Sun, 31 Jan 2010 21:52:35 -0800 (PST) Received: from poweredge.velvetsea.net (69-183-236-39.ded.snet.net [69.183.236.39]) (authenticated bits=0) by pantheon-po29.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id o115qnL4026638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Feb 2010 00:52:55 -0500 Received: from laptop.localnet (unknown [192.168.1.78]) by poweredge.velvetsea.net (Postfix) with ESMTPSA id D50FA42401C; Mon, 1 Feb 2010 00:52:46 -0500 (EST) From: Richard Alimi To: Wesley Leggette Date: Mon, 1 Feb 2010 00:52:45 -0500 User-Agent: KMail/1.12.4 (Linux/2.6.31-gentoo-r6; KDE/4.3.4; x86_64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002010052.45922.richard.alimi@yale.edu> X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) Cc: DECADE Subject: Re: [decade] Updated DECADE Charter 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, 01 Feb 2010 05:52:37 -0000 Hi Wesley, Thank you very much for your interest and it is great to get your input, even though it is quite clear that we have different goals :) Please see inline: On Friday 29 January 2010 8:35:52 pm Wesley Leggette wrote: > As I've said before, I'm also interested in a more general purpose > distributed network storage protocol. Specifically, it would be nice to > have a standards-based protocol with at least the primitives necessary to > support a distributed file system. These would include at the very least > proper revision/commit safeties and support for some form of distributed > write locking. While I do agree that such a protocol interesting, I also believe that would be far beyond what we are targeting in DECADE. With some very basic capabilities (e.g., without distributed locking, without commitment, etc), we can already support the class of applications we are targeting. > As for analyzing whether compatibility with other applications makes sense > for DECADE, I know off hand of quite a few differences which could make it > difficult to merge DECADE's original goal with a more general storage > network protocol. Yes, I fully agree that there would be (quite large) differences between the original goal and a more general storage network protocol. This is primarily the reason that I think we would like to keep our scope more narrow. > The main difference is in the way the presence of data is communicated. P2P > is generally geared towards out-of-band advertising and in-band pull (the > download from the peer) and replicate (when the data is cached locally on > the requesting client). With a storage system, clients expect to be able to > push data, and this presents timing problems when it comes time to > advertise what data was just written. How do other users know if data has > been written? In our thinking for DECADE, other users are notified via the native P2P protocols. Something similar could be done with integration in other applications (e.g., inside Flash for YouTube). > Is it advertised out-of-band after the entire data set is > written? In our thinking for DECADE, but the DECADE protocol doesn't have to deal with this since, as you mentioned, it is out-of-band. > This is an approach similar to BitTorrent where you have to > obtain torrent files somehow after the first seed is complete. Is there an > in-band mechanism to list or query what is out there in a generic way? I presume DECADE would have an operation to list which objects are currently stored at a particular server. My feeling is that it would be more complicated than we need to support search for stored objects across the network. In our context, that could be done in the P2P protocols themselves (e.g., objects may be advertised via a DHT or the normal buffer map exchanges). Other applications could also have something like this. > If > so, when is data visible in the in-band mechanism; during a write or after > all writes are complete? For DECADE, in the P2P case anyways, each object may just be a piece of the file anyways. An object can be visible directly after it is written (and maybe even optimized to be visible as it is being written). I do realize that you are asking these questions in the context of a more general distributed storage protocol, and that my answers are focused on the use cases for DECADE. I'm basically trying to illustrate how much simpler the protocol design can be with our original goal. > > Also, if the goal is for "other applications", are these > write-once-read-many systems, or can data be overwritten? If the system is > designed to allow data to be overwritten then there has to be a mechanism > to safely update multi-part data (so that a large file can be stored in > smaller segments and the correct matching segment versions are always > available). In our case, I envision we are going for write-once-read-many. This would be sufficient for P2P applications that chop their data into smaller pieces anyways. The clients can upload and download data in pieces - but the storage system doesn't even have to know that they form a larger file. > > If DECADE ends up being just a way to cache data requests made through a > particular P2P system, it's also worth noting that different P2P systems > use different data formats. If DECADE just provides format unaware storage > this could mean that data will have to be stored twice if its made > available over different P2P applications. Two comments here. First, keep in mind that each user can have his or her own storage (DECADE is not envisioned just a standard "caching" protocol). Thus, two users can have the same object (even in the same format) -- if the storage system wishes to actually have the objects point the same block of storage, then that is fine - it is out-of-scope for the protocol. Second, we are not trying to standardize a data format in which objects need to be stored - each application can store in whatever format it chooses. You're right that this may produce data that would need to be stored twice. > While I'm not sure that DECADE wants to deal with any of these issues, it > could very well be worth creating a second working group to deal with > general purpose distributed storage system. Personally, I would actually be very interested to follow such a working group :) Thanks again for your interest and feedback! -- Richard Alimi Department of Computer Science Yale University From richard.alimi@yale.edu Sun Jan 31 22:01:41 2010 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 B45033A68B3 for ; Sun, 31 Jan 2010 22:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.739 X-Spam-Level: X-Spam-Status: No, score=-3.739 tagged_above=-999 required=5 tests=[AWL=-1.140, 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 gGsLnApxxGEN for ; Sun, 31 Jan 2010 22:01:39 -0800 (PST) Received: from pantheon-po33.its.yale.edu (pantheon-po33.its.yale.edu [130.132.50.94]) by core3.amsl.com (Postfix) with ESMTP id 7078E3A6804 for ; Sun, 31 Jan 2010 22:01:39 -0800 (PST) Received: from poweredge.velvetsea.net (69-183-236-39.ded.snet.net [69.183.236.39]) (authenticated bits=0) by pantheon-po33.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id o11621CU012925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Feb 2010 01:02:02 -0500 Received: from laptop.localnet (unknown [192.168.1.78]) by poweredge.velvetsea.net (Postfix) with ESMTPSA id A948242401C; Mon, 1 Feb 2010 01:02:01 -0500 (EST) From: Richard Alimi To: Song Haibin Date: Mon, 1 Feb 2010 01:02:00 -0500 User-Agent: KMail/1.12.4 (Linux/2.6.31-gentoo-r6; KDE/4.3.4; x86_64; ; ) References: <006d01caa14c$79419cd0$310ca40a@china.huawei.com> In-Reply-To: <006d01caa14c$79419cd0$310ca40a@china.huawei.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002010102.00412.richard.alimi@yale.edu> X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) Cc: decade@ietf.org Subject: Re: [decade] Updated DECADE Charter 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, 01 Feb 2010 06:01:41 -0000 I agree that doing a survey of every application that might use in-network storage would be quite a daunting task, and that it makes sense to keep our problem narrower. That said, I was trying to think of a good way to characterize a broader set of applications than "P2P" that we can target, as I do agree that applications such as YouTube and IPTV might have some good use cases. Might it be fair to say that we can target applications that distribute large data files that might be subdivided in to smaller pieces? As for wording in the charter, how about something like: ... The protocol will be focused on P2P applications and similar applications that can subdivide data into smaller pieces for distribution. Thoughts? -- Richard Alimi Department of Computer Science Yale University On Friday 29 January 2010 8:35:15 pm Song Haibin wrote: > I would like to hear other people's opinions. My personal feeling is that > it will get things a little complicated. You have to do a survey of > resource/access control behaviors for other types of applications which > will possibly use in-network storage, that will broaden the scope a lot. > > > Xie Xie, > Haibin > > > -----Original Message----- > > From: Strandberg, Ove (NSN - FI/Espoo) > > [mailto:ove.strandberg@nsn.com] > > Sent: Friday, January 29, 2010 6:41 PM > > To: ext Song Haibin; ext Enrico Marocco; Richard Alimi > > Cc: decade@ietf.org > > Subject: RE: [decade] Updated DECADE Charter > > > > Hi Haibin, > > > > Thanks for your comments. > > > > My main concern with P2P as use case is that other > > interaction towards a network storage other than originating > > from a P2P client will not be considered. I could easily > > imagine the benefit of network storage for examples for > > applications like Spotify, Youtube, IPTV etc.. They can > > potentially be interedsted in memory utilization too. Thus > > there are other potential use of a network storage protocol. > > The relationship of these towards a network storage looks > > different from a P2P client perspective and designing from > > only P2P in first step potentially limiting. > > > > This use case concern is of principal matter (me thinks) and > > the charter should reflect this already now. This change does > > not change the fact that most interest might be on solving > > the P2P use case, but there are more use cases that should be > > included in the charter description. > > > > Br, > > > > +Ove > > > > >-----Original Message----- > > >From: ext Song Haibin [mailto:melodysong@huawei.com] > > >Sent: 29 January, 2010 04:56 > > >To: Strandberg, Ove (NSN - FI/Espoo); 'ext Enrico Marocco'; 'Richard > > >Alimi' > > >Cc: decade@ietf.org > > >Subject: RE: [decade] Updated DECADE Charter > > > > > > > > >Hi Ove, > > > > > >Thanks for the good comment. It is very useful if the > > > > protocol can be > > > > >used by other types of applications. But If you consider other > > >applications for the first step, you have to incorporate other > > >features. For example, you may need replicas in the > > > > in-network storage > > > > >to guarantee QoS. I prefer to focus on P2P applications > > > > initially, but > > > > >keep other applications in mind, so that later extensions > > > > can be made > > > > >to let better integration with other applications. > > > > > >Xie Xie, > > >Haibin > > > > > >> -----Original Message----- > > >> From: decade-bounces@ietf.org > > >> [mailto:decade-bounces@ietf.org] On Behalf Of Strandberg, > > > > Ove (NSN - > > > > >> FI/Espoo) > > >> Sent: Wednesday, January 27, 2010 6:13 PM > > >> To: ext Enrico Marocco; Richard Alimi > > >> Cc: decade@ietf.org > > >> Subject: Re: [decade] Updated DECADE Charter > > >> > > >> Hi all, > > >> > > >> At the pre-BOF in Stockholm also other applications than P2P was > > >> discussed. I probably missed some of the discussion in > > > > > >Hiroshima, but > > > > > >> I would appriciate shifting focus from P2P intpo more > > > > generic use of > > > > >> network storage, eg. We should not get into too P2P specific > > > > > >solution. > > > > > >> The statement: > > >> > > >> "The protocol will be focused on P2P applications, though it > > > > > >may also > > > > > >> be used in other types of applications." > > >> > > >> Could be reworked: > > >> > > >> "The protocol will be focused on P2P applications, though it > > > > > >should be > > > > > >> generic to allow usage in other types of applications also." > > >> > > >> Br, > > >> > > >> +Ove > > >> > > >> Ps. I also have background in Network of Information in > > > > > >4WARD project. > > > > > >> Ds. > > >> > > >> >-----Original Message----- > > >> >From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On > > >> >Behalf Of ext Enrico Marocco > > >> >Sent: 27 January, 2010 12:02 > > >> >To: Richard Alimi > > >> >Cc: decade@ietf.org > > >> >Subject: Re: [decade] Updated DECADE Charter > > >> > > > >> >Thanks for putting this together! > > >> > > > >> >In general I like text, but one thing I think we should do very > > >> >carefully is to precisely list what we are sure is missing from > > >> >existing protocols -- fine grained access and resource > > >> > > >> control, right? > > >> > > >> >-- as, at the end of the day, that will be the reason why > > >> > > >> the IESG may > > >> > > >> >decide to charter a new WG. To this extent, I'd prefer to be more > > >> >explicit, at the risk of being redundant, e.g. in the last > > >> > > >> sentence of > > >> > > >> >paragraph 3: > > >> > > > >> > Though there are existing data access protocols (e.g., > > > > HTTP, NFS, > > > > >> > WebDAV), they lack capabilities needed when applied in > > > > > >this context. > > > > > >> >What about replacing it with something along this line? > > >> > > > >> > Though there are existing data access protocols (e.g., > > > > HTTP, NFS, > > > > >> > WebDAV), they lack capabilities for fine-grained access and > > >> > > >> resource > > >> > > >> > control that are essential for today's advanced P2P algorithms. > > >> > > > >> >Enrico > > >> > > > >> >Richard Alimi wrote: > > >> >> Hi All, > > >> >> > > >> >> We have been working on a new charter with a refined scope and > > >> >> incorporating past discussion on the mailing list. It would be > > >> >> wonderful to hear comments on the new proposed charter. > > >> > > > >> >============================================================= > > >> > > >> ========= > > >> > > >> >> == > > >> >> > > >> >> DECoupled Application Data Enroute > > >> >> > > >> >> Description of Working Group: > > >> >> > > >> >> Peer-to-Peer (P2P) applications, including both P2P > > >> > > > >> >streaming and P2P > > >> > > > >> >> file- sharing applications, make up a large fraction of > > >> > > > >> >traffic in the > > >> > > > >> >> Internet today. One way to reduce access network and/or > > >> > > >> cross-domain > > >> > > >> >> bandwidth usage by P2P applications is to introduce storage > > >> > > > >> >capabilities in the networks. > > >> > > > >> >> Allowing P2P applications to store and retrieve data > > > > from inside > > > > >> >> networks can reduce traffic on the last-mile uplink, as well > > >> > > > >> >as backbone and transit links. > > >> > > > >> >> Existing P2P caches often implement the specific P2P > > > > application > > > > >> >> protocols to operate transparently or act as super peers to > > >> > > > >> >provide in-network storage. > > >> > > > >> >> However, this approach poses challenges to both P2P cache > > >> > > > >> >vendors and > > >> > > > >> >> P2P application developers. For P2P cache vendors, the > > >> > > > >> >challenge is to > > >> > > > >> >> support a variety of exisiting and evolving protocols. For P2P > > >> >> applications, closed P2P caching systems limit effective > > >> > > >> utilization > > >> > > >> >> of in-network storage. Some P2P protocols may be entirely > > >> > > > >> >unsupported, > > >> > > > >> >> and applications may be better-equipped to decide how > > > > in-network > > > > >> >> storage is used to meet their specific requirements (e.g., > > >> > > > >> >data placement, access control and resource control). > > >> > > > >> >> Both of these challenges can be effectively addressed > > > > by using an > > > > >> >> open, standard protocol to access in-network storage. P2P > > >> > > > >> >applications > > >> > > > >> >> can store and retrieve content in the in-network storage, > > >> > > >> as well as > > >> > > >> >> control resources (e.g., bandwidth, connections) consumed by > > >> > > > >> >peers in > > >> > > > >> >> a P2P application. As a simple example, a peer can choose > > >> > > >> to store > > >> > > >> >> content in the in-network storage, and direct other peers to > > >> > > > >> >retrieve > > >> > > > >> >> from that location, reducing last-mile link usage. Though > > >> > > >> there are > > >> > > >> >> existing data access protocols (e.g., HTTP, NFS, WebDAV), > > >> > > > >> >they lack capabilities needed when applied in this context. > > >> > > > >> >> The Working Group (WG) will design and specify a standard > > >> > > > >> >protocol for > > >> > > > >> >> P2P applications to utilize in-network storage. The > > > > > >protocol will > > > > > >> >> include operations for a P2P application to (1) store, > > >> > > >> retrieve, and > > >> > > >> >> manage data, (2) specify access control for storing and > > > > > >retrieving > > > > > >> >> data suitable for a P2P environment with peers across multiple > > >> >> administrative and security domains, and (3) indicate > > >> > > > >> >resource control policies for storing and retrieving data. > > >> > > > >> >> The WG will leverage existing IETF protocols where possible, in > > >> >> particular for storing, retrieving, and managing data. > > >> >> > > >> >> This WG will focus mainly on the protocol between the > > > > in-network > > > > >> >> storage and P2P applications. The protocol will be > > > > > >focused on P2P > > > > > >> >> applications, though it may also be used in other types of > > >> > > > >> >applications. > > >> > > > >> >> The WG will focus on the following work items: > > >> >> > > >> >> - A "problem statement" document. This document provides a > > >> > > > >> >description of the > > >> > > > >> >> problem and common terminology. > > >> >> > > >> >> - A requirements document. This document lists the > > >> > > > >> >requirements for the > > >> > > > >> >> in-network storage service (e.g., supported operations) > > >> > > > >> >and the protocol to > > >> > > > >> >> support it. > > >> >> > > >> >> - A survey document. This document will survey existing > > >> > > > >> >related mechanisms > > >> > > > >> >> and protocols (e.g., HTTP, NFS, and WebDAV), and > > > > evaluate their > > > > >> >> applicability and effectiveness. > > >> >> > > >> >> - A signaling protocol for storing, retrieving, and managing > > >> > > > >> >data as well as > > >> > > > >> >> specifying both access control and resource control > > >> > > >> policies in the > > >> > > >> >> in-network storage pertaining to that data. Data storage, > > >> > > > >> >retrieval, and > > >> > > > >> >> management may be provided by an existing IETF protocol. > > >> > > > >> >If the underlying > > >> > > > >> >> protocol does not support certain data management > > >> > > > >> >operations, DECADE may > > >> > > > >> >> seek to define such extensions and present them to the > > >> > > > >> >respective working > > >> > > > >> >> groups or create an Individual Submission if no active > > >> > > > >> >working group exists. > > >> > > > >> >> This group may also create a profile of necessary > > >> > > > >> >operations from an > > >> > > > >> >> existing IETF protocol to reduce the complexity and > > >> > > > >> >software footprint of a > > >> > > > >> >> compliant implementation. > > >> >> > > >> >> The WG will not limit itself to a single underlying > > >> > > > >> >protocol since different > > >> > > > >> >> underlying protocols may have varying implementation costs > > >> > > > >> >and performance > > >> > > > >> >> tradeoffs. To keep interoperability manageable, a small > > >> > > > >> >number of specific, > > >> > > > >> >> targeted, underlying protocols will be used. NFS and > > >> > > > >> >WebDAV are initial > > >> > > > >> >> targets and others may be incorporated with WG consensus. > > >> >> > > >> >> - An informational document describing the integration of > > >> > > > >> >DECADE with existing > > >> > > > >> >> P2P applications (e.g., integration with BitTorrent). > > >> >> > > >> >> The following issues are not considered in the current scope > > >> > > > >> >of the WG: > > >> >> - Copyright protected or illegal content > > >> >> For example, one possibility is that that an in-network > > >> > > > >> >storage system may > > >> > > > >> >> have system-wide ingress and egress filters to implement > > >> > > > >> >policies related to > > >> > > > >> >> copyrighted and illegal content. This is outside the > > >> > > > >> >scope of this working > > >> > > > >> >> group. > > >> >> > > >> >> - Locating the "best" in-network storage location from which > > >> > > > >> >to retrieve > > >> > > > >> >> content if there are more than one location can provide > > >> > > > >> >the same content. > > >> > > > >> >> - Developing a new protocol to deliver content between P2P > > >> > > > >> >application and > > >> > > > >> >> in-network storage. > > >> >> > > >> >> Goals and Milestones: > > >> >> > > >> >> May 2010 Working Group Last Call for problem statement > > > > Aug 2010 > > > > >> >> Submit problem statement to IESG as Informational Aug 2010 > > >> > > >> Working > > >> > > >> >> Group Last Call for requirements document Feb 2011 Submit > > >> >> requirements document to IESG as Informational May 2011 > > >> > > > >> >Working Group > > >> > > > >> >> Last Call for survey document Aug 2011 Working Group Last > > >> > > >> Call for > > >> > > >> >> in-network storage access protocol Aug 2011 Submit survey > > >> > > > >> >document to > > >> > > > >> >> IESG as Informational Nov 2011 Submit in-network > > > > storage access > > > > >> >> protocol to IESG as Proposed > > >> >> Standard > > >> > > > >> >============================================================= > > >> > > >> ========= > > >> > > >> >> == > > >> >> > > >> >> Thanks! > > >> > > >> _______________________________________________ > > >> decade mailing list > > >> decade@ietf.org > > >> https://www.ietf.org/mailman/listinfo/decade >