From christian.1.schmidt@nsn.com Mon Feb 1 00:47: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 E54D13A69DC for ; Mon, 1 Feb 2010 00:47:15 -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 OYqNwZFbxhQd for ; Mon, 1 Feb 2010 00:47:13 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id D08D63A697C for ; Mon, 1 Feb 2010 00:47:12 -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 o118lfER008163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 1 Feb 2010 09:47:41 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o118le3K010229; Mon, 1 Feb 2010 09:47:40 +0100 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 09:47:40 +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: Mon, 1 Feb 2010 09:47:39 +0100 Message-ID: In-Reply-To: <201002010102.00412.richard.alimi@yale.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] Updated DECADE Charter Thread-Index: AcqjBB1Ubxvj1498Qf2ShdXvEqOQggAFdMmw References: <006d01caa14c$79419cd0$310ca40a@china.huawei.com> <201002010102.00412.richard.alimi@yale.edu> From: "Schmidt, Christian 1. (NSN - DE/Munich)" To: "ext Richard Alimi" , "Song Haibin" X-OriginalArrivalTime: 01 Feb 2010 08:47:40.0173 (UTC) FILETIME=[362B43D0:01CAA31B] 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 08:47:16 -0000 It would be good to keep focused on the originally planned goals for the group. There were a lot of discussions on the list, related to possible, urgent needed Or nice to have extenstion with "minor" additional requirements. Lets take care Of them in a second step, if needed. My proposal for the charter text: "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 with similar protocol requirements."=20 What do you think about this proposal? BR Christian Schmidt =20 -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of ext Richard Alimi Sent: Monday, February 01, 2010 7:02 AM To: Song Haibin Cc: decade@ietf.org Subject: Re: [decade] Updated DECADE Charter I agree that doing a survey of every application that might use in-network=20 storage would be quite a daunting task, and that it makes sense to keep our=20 problem narrower. That said, I was trying to think of a good way to characterize a broader set=20 of applications than "P2P" that we can target, as I do agree that applications=20 such as YouTube and IPTV might have some good use cases. Might it be fair to=20 say that we can target applications that distribute large data files that=20 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? --=20 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. >=20 >=20 > Xie Xie, > Haibin >=20 > > -----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. > > >> > > > >> = >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 >=20 _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade From melodysong@huawei.com Mon Feb 1 01:17:35 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 138D928C14C for ; Mon, 1 Feb 2010 01:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[AWL=1.049, 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 RGZ0qHbzlbtd for ; Mon, 1 Feb 2010 01:17:34 -0800 (PST) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 9E99F28C148 for ; Mon, 1 Feb 2010 01:17:33 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KX50080COHLET@szxga02-in.huawei.com> for decade@ietf.org; Mon, 01 Feb 2010 17:17:46 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KX500IJXOHGYR@szxga02-in.huawei.com> for decade@ietf.org; Mon, 01 Feb 2010 17:17:40 +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 <0KX5002IGOGYUZ@szxml04-in.huawei.com> for decade@ietf.org; Mon, 01 Feb 2010 17:17:25 +0800 (CST) Date: Mon, 01 Feb 2010 17:17:17 +0800 From: Song Haibin In-reply-to: <201001312356.09019.richard.alimi@yale.edu> To: 'Richard Alimi' , =?ISO-8859-1?Q?'B=F6rje_Ohlman'?= Message-id: <00be01caa31f$5c8cde90$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=ISO-8859-1 Content-transfer-encoding: quoted-printable Thread-index: Acqi+vDcOMzTxdCZSNacSGPK/H9D1QAHyfeg 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 09:17:35 -0000 Hi B=F6rje, Thanks for your interest. For the second comment on mobility, I don't = think you mean IP mobility protocols. The existing underlying protocol can = already support it. So there is no problem for the basic mobility issue. As for i3, I know some about it and like it very much, and do think it = works well for mobility issues. In DECADE, the DECADE server can already be = an anchor point. That said, the sender can send the data to its in-network storage, and it does not need to be aware of the receiver's address. The receiver can also get the data from this in-network storage and does not need to be aware of the sender' address (although the receiver needs to = get the authorization to access the data, e.g. get a token from the sender) = . The DECADE server can maitain the connectivity when both the end-points move. Just like what an i3 server does. But we don't need to describe it = in so detail in the charter. Are you satisfied with this or is there any = new function that you think should be basically supported by DECADE? I also support to leave automatic data migration out of scope. Xie Xie, Haibin =20 > -----Original Message----- > From: decade-bounces@ietf.org=20 > [mailto:decade-bounces@ietf.org] On Behalf Of Richard Alimi > Sent: Monday, February 01, 2010 12:56 PM > To: B=F6rje Ohlman > Cc: decade@ietf.org > Subject: Re: [decade] Updated DECADE Charter >=20 > Hi B=F6rje, >=20 > 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=20 > > complex, not if it is designed in from the beginning (e.g. see=20 > > Internet Indirection Infrastructure (i3)), it is when it is=20 > added as=20 > > an afterthought things get complex. That is why I think=20 > that support=20 > > for basic node mobility should at least be considered. > >=20 > > I also think the two issues 'copies' and 'mobility' are=20 > related to a=20 > > certain extent. Being able to use locally available copies=20 > rather than=20 > > to have to access 'your own' remote or migrated copy can simplify=20 > > mobility significantly. >=20 > Comments below... >=20 > >=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=20 > storage I think=20 > > >> it would be good to make clear if the network part of=20 > DECADE can =20 > > >> benefit when multiple users/application stores the same=20 > information=20 > > >> object (e.g. file). Is it then possible for DECADE to store only=20 > > >> one copy of the information object or is it required to store=20 > > >> multiple copies of the same object? > > > > > > While this is an optimization that could be worthwhile,=20 > my feeling=20 > > > is that it does not matter with respect to the protocol=20 > between the=20 > > > application and the storage. If the storage system were to have=20 > > > such a feature, it may be an implementation detail. Are you=20 > > > envisioning a case where this would surface in the protocol? > >=20 > > How you refer to an object, e.g. by relative or absolute=20 > references,=20 > > has an influence on how easy it is to identify a copy of an=20 > object. If=20 > > you use relative path names to refer to objects see that=20 > two objects=20 > > are the same. >=20 > I think I am beginning to see where you are coming from here.=20 > My response above was in the more general case, where the=20 > storage system automatically detected objects that contained=20 > exactly the same data, and then, as an optimization in the=20 > implementation, deleted one and replaced it with a link (e.g,=20 > a hardlink) to the other. This would have the effect of=20 > reducing redundancy across multiple users using storage at=20 > the same server. Note that it would *not* be safe to only do=20 > this based on the naming of the object. >=20 > However, it sounds like you are referring to a user=20 > explicitly creating links to objects within his or her own=20 > storage - is this an accurate characterization? If not, can=20 > you provide an example? >=20 > When it comes to defining exactly which management operations=20 > would be=20 > supported by DECADE, this is already in the charter. I=20 > believe links between=20 > objects would be considered a management operation and this=20 > would be fair game. >=20 > You've also touched on the naming here. This is something=20 > that would have to be decided as well within the WG, but is=20 > probably not important for the charter. >=20 > I'd be good to get opinions from others here as well. >=20 > > >> 2) Should DECADE support mobility of=20 > terminals/users/applications? > > >> A lot of today's terminals are mobile, e.g. laptops and=20 > smartphones. > > >> When they move should their in-network storage move with them or=20 > > >> should access to their storage be made by tunneling back to some=20 > > >> type of "home storage"? > > > > > > I think this is a good discussion to have and it would be=20 > great to=20 > > > get opinions from others. My personal feeling is to leave=20 > automatic=20 > > > data migration out of scope, since it may make the system=20 > quite complicated. > > > In particular, one of the things we explicitly mentioned as=20 > > > out-of-scope was finding the "best" in-network storage element. I=20 > > > think that what you mention here for mobility is somewhat=20 > related to this. > >=20 > > If we don't want to get into data migration and trying to find 'the=20 > > best' copy I would settle to for agreeing that it is ok to=20 > use locally=20 > > available copies if they happens to be around. As I indicated above=20 > > this could simplify giving some basic support for nodes=20 > that are not=20 > > permanently stationary in the network. >=20 > Yes, I certainly agree that it should be possible for clients=20 > to use a closer copy if it is available. One way I can see=20 > for providing such functionality without needing automatic=20 > data migration is for a client to locally have a list of=20 > DECADE servers (e.g., DNS names) available to it, and the=20 > client locally picks the most-desired one with the data it needs. >=20 > Are there other possibilities (not using data migration) that=20 > you were thinking about? >=20 > > > The idea is that we'd like to be able to use existing=20 > storage access=20 > > > protocols where possible. The candidates that we mention in the=20 > > > charter currently are NFS and WebDAV. However, in=20 > DECADE, we need=20 > > > to pass some additional information between the user and=20 > in-network=20 > > > storage (e.g., resource control and access control). Do you have=20 > > > suggestions for an alternate wording here? > >=20 > > If the current thinking is that we want to try to find a suitable=20 > > protocol to be reused I think it is a bit premature to state that=20 > > developing a new protocol is out of scope before we have=20 > even defined=20 > > the requirements for the functionality of the new protocol. >=20 > We have an initial copy of the requirements draft and have=20 > done some initial thinking about how it might be applied to=20 > NFS or WebDAV. We have also left the charter open to=20 > providing extensions where necessary. >=20 > Is there certain functionality that you believe would just=20 > fundamentally not align with such protocols (meaning=20 > extensions would not be a good approach)? >=20 > -- > Richard Alimi > Department of Computer Science > Yale University > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade >=20 From melodysong@huawei.com Mon Feb 1 01:27: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 A7FB728C163 for ; Mon, 1 Feb 2010 01:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[AWL=-0.115, 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 fJlr6gtyk3JB for ; Mon, 1 Feb 2010 01:27:51 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 4878228C15F for ; Mon, 1 Feb 2010 01:27:50 -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 <0KX500I0QOYPNN@szxga03-in.huawei.com> for decade@ietf.org; Mon, 01 Feb 2010 17:28:02 +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 <0KX5009XROYJAU@szxga03-in.huawei.com> for decade@ietf.org; Mon, 01 Feb 2010 17:27:55 +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 <0KX5002GAOY1UZ@szxml04-in.huawei.com> for decade@ietf.org; Mon, 01 Feb 2010 17:27:40 +0800 (CST) Date: Mon, 01 Feb 2010 17:27:32 +0800 From: Song Haibin In-reply-to: To: "'Schmidt, Christian 1. (NSN - DE/Munich)'" , 'ext Richard Alimi' Message-id: <00c501caa320$cb263440$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: AcqjBB1Ubxvj1498Qf2ShdXvEqOQggAFdMmwAAGCOKA= 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 09:27:52 -0000 Hi Christian, Thanks for your response. See in line. > -----Original Message----- > From: Schmidt, Christian 1. (NSN - DE/Munich) > [mailto:christian.1.schmidt@nsn.com] > Sent: Monday, February 01, 2010 4:48 PM > To: ext Richard Alimi; Song Haibin > Cc: decade@ietf.org > Subject: RE: [decade] Updated DECADE Charter > > It would be good to keep focused on the originally planned > goals for the group. > Agree. > There were a lot of discussions on the list, related to > possible, urgent needed Or nice to have extenstion with > "minor" additional requirements. Lets take care Of them in a > second step, if needed. > Agree too. We can leave the minor additional requirements to when we design the control protocol. > My proposal for the charter text: > "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 with similar protocol requirements." > > What do you think about this proposal? > Thanks and I like it very much : ) Xie Xie, Haibin > BR > Christian Schmidt > > > > -----Original Message----- > From: decade-bounces@ietf.org > [mailto:decade-bounces@ietf.org] On Behalf Of ext Richard Alimi > Sent: Monday, February 01, 2010 7:02 AM > To: Song Haibin > Cc: decade@ietf.org > Subject: Re: [decade] Updated DECADE Charter > > 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 > > > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > From lars.eggert@nokia.com Mon Feb 1 02:21:03 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 A3A9C28C10D for ; Mon, 1 Feb 2010 02:21:03 -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 09IsjDM+Ztgt for ; Mon, 1 Feb 2010 02:21:02 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 6D06E28C177 for ; Mon, 1 Feb 2010 02:21:01 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o11ALDLu025672; Mon, 1 Feb 2010 12:21:32 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 12:21:17 +0200 Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 12:21:13 +0200 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o11ALBer006629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Feb 2010 12:21:11 +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-27--1050349534; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <201001312325.24411.richard.alimi@yale.edu> Date: Mon, 1 Feb 2010 12:20:59 +0200 Message-Id: <6F0E7A7C-14D6-4C09-83EE-9F2B5CBAD132@nokia.com> References: <201001221658.24381.richard.alimi@yale.edu> <201001270919.18847.richard.alimi@yale.edu> <96A9D5A9-A584-4905-AD5F-58EC1A588E3E@nokia.com> <201001312325.24411.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]); Mon, 01 Feb 2010 12:21:05 +0200 (EET) X-OriginalArrivalTime: 01 Feb 2010 10:21:13.0062 (UTC) FILETIME=[47B62860:01CAA328] 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: Mon, 01 Feb 2010 10:21:03 -0000 --Apple-Mail-27--1050349534 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-2-1, at 6:25, Richard Alimi wrote: > Thanks for the response. First, I'd like to clarify that we're on the = same=20 > page in regards to the intended WG scope. We will indeed re-use = existing=20 > underlying protocols wherever possible. there's an assumption here that DECADE will result in a separate = protocol, potentially layered in top of existing protocols like NFS or = WebDAV. Why are we already convinced that this is what the design would = look like? I can equally well envision an outcome where the DECADE effort results = in a BCP that says "here is how you configure one or more NFS (or = WebDAV) servers for caching media chunks, and here's how you'd implement = cache access in a P2P client." In other words, there wouldn't be a = separate protocol but "just" configuration and practices of how to use = NFS or WebDAV for what's needed for this deployment case. > According to the currently-proposed=20 > charter, the new WG would be responsible for: >=20 > - 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. Right. This is similar to what I had as a design counterexample above. > - 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. =46rom what I've seen, this step (DECADE needing to be a separate = protocol) is not sufficiently motivated. > I'm also trying to understand your viewpoint a bit better here. Are = you of=20 > the opinion that NFS is the only protocol that should be extended? Not at all. I'm saying that we have successful storage protocols (NFS, = WebDAV) and it's unclear to me that we need a third protocol just for = this deployment scenario. I simply haven't seen a conclusive argument = for it.=20 Lars --Apple-Mail-27--1050349534 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 MQ8XDTEwMDIwMTEwMjA1OVowIwYJKoZIhvcNAQkEMRYEFGNBeaiejZpCtK6m4TKiX1c/9b2wMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQBHkmg2JgV4j+9Y3PM4LD0tJeSeFtOseHX2s4jh+qS0COHWAxwlh7ZO7uGkPg8DUJzqyYI0 pSvM1hFZe2gdCwAfqx3K0sAPWPbcJmVdMcWyUuErF3w7eOBRFSB15t+A0jwFtLQMTmeipErrGVDa jxTvf5mqjyvS5PqYPXN25OJ1tD3aEr9IkhcY+od9mOmGbdOBwZ+7nMd15//dQZytKKljWsEVAOYw YpYuwOsHYrXw+cFLq44OxcPjAGwB5vmH8LoL5SBQfRaV/+JjVK35evHzEJadgsawU+4TRPg1onI1 zHopMxW2On4908jaZ8GJOGgpqVBbxfNhzgPIVlZQ5XETAAAAAAAA --Apple-Mail-27--1050349534-- From wleggette@cleversafe.com Mon Feb 1 09:35:51 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 8F8FC28C165 for ; Mon, 1 Feb 2010 09:35:51 -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 gX4-oTkwMV8C for ; Mon, 1 Feb 2010 09:35:50 -0800 (PST) Received: from p01c12o149.mxlogic.net (p01c12o149.mxlogic.net [208.65.145.72]) by core3.amsl.com (Postfix) with ESMTP id 7167328C110 for ; Mon, 1 Feb 2010 09:35:50 -0800 (PST) Received: from unknown [216.166.12.98] (EHLO p01c12o149.mxlogic.net) by p01c12o149.mxlogic.net(mxl_mta-6.5.0-0) with ESMTP id 911176b4.da4fbb90.11595.00-432.24729.p01c12o149.mxlogic.net (envelope-from ); Mon, 01 Feb 2010 10:36:25 -0700 (MST) X-MXL-Hash: 4b671119009eac29-39be7acb70d8bef31c39e8385bf253bdfafb2c19 Received: from unknown [216.166.12.98] by p01c12o149.mxlogic.net(mxl_mta-6.5.0-0) with SMTP id cf0176b4.0.7882.00-021.24426.p01c12o149.mxlogic.net (envelope-from ); Mon, 01 Feb 2010 10:35:58 -0700 (MST) X-MXL-Hash: 4b6710fe650b3f73-36372db1c87e800a75829095161b56432ccc6ca6 Received: from AUSP01VMBX09.collaborationhost.net ([10.2.8.161]) by AUSP01MHUB07.collaborationhost.net ([10.2.8.242]) with mapi; Mon, 1 Feb 2010 11:35:07 -0600 From: Wesley Leggette To: Richard Alimi Date: Mon, 1 Feb 2010 11:35:00 -0600 Thread-Topic: [decade] Updated DECADE Charter Thread-Index: AcqjBC2mLUlHq6toS3GWcK5YKB3q1gAYLNQl Message-ID: In-Reply-To: <201002010052.45922.richard.alimi@yale.edu> 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.98] X-AnalysisOut: [v=1.0 c=1 a=IRTT+DMug47mVLgYdXzmDg==:17 a=Ltt78-zykJdswTGI] X-AnalysisOut: [WREA:9 a=RWg8wVKT-S6XJvUFVdBg0VQpVbMA:4] Cc: ext, 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 17:35:51 -0000 On 1/31/10 23:52, "Richard Alimi" wrote: >=20 > 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 simple= r the > protocol design can be with our original goal. I agree that a simple WORM system for P2P application-specific object storage is much simpler to design. I'm glad to see that the scope and use cases are going to be constrained as, yes, my point was that to not limit the scope would would vastly complicate the requirements. What I think is interesting is that this is really meant as an in-network storage for application-specific use. This is to say, while it is meant for generic storage, it is not meant for generic cross-application *access*. After realizing this, looking back over the use cases, they were a lot more clear to me. I've come up with the following analogy which has helped me to understand the scope of DECADE. While I don't have any more specific comments, I share it here in the hopes of helping anyone else who is similarly confused: I now view the scope of DECADE as a sort of "one-way" approach that is counter-intuitive when you think of it in terms of network storage protocol= s such as CIFS, WebDAV, and NFS, which all have a fixed data model (the "file system paradigm") and are meant for various clients to be able to understan= d what the data is to some degree (as, at least, files, if not the format of the files themselves). When you think of this in terms of more general "cloud storage" such as Amazon S3, the picture becomes a bit clearer. In that sort of system, the point isn't to define a data model for client interoperability, just to provide a shared mechanism for storing data. It is up to the application written on top to interpret how the data fits together when it is accessed. This is probably all very obvious to most of you, of course, but as P2P and "cloud storage" is still fairly new, it's probably worth mentioning at some level. =20 >> While I'm not sure that DECADE wants to deal with any of these issues, i= t >> could very well be worth creating a second working group to deal with >> general purpose distributed storage system. >=20 > Personally, I would actually be very interested to follow such a working = group > :) I'll make sure to keep this list informed. I should note that we fully embrace the sort of "object-based", "no-paradigm" storage DECADE is all about, but my goal with another working group would be to build a slightly more complicated base storage protocol which would allow vendors to build (or simulate) more traditional access patterns like "file system" and "block device" on top of it. Not the scope of DECADE, but that is fine. Wesley Leggette Cleversafe, Inc. From davidbryan@gmail.com Mon Feb 1 10:11:12 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 2DF753A67E3 for ; Mon, 1 Feb 2010 10:11:12 -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=[AWL=0.000, 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 HXpo67cKfOOn for ; Mon, 1 Feb 2010 10:11:11 -0800 (PST) Received: from mail-yx0-f174.google.com (mail-yx0-f174.google.com [209.85.210.174]) by core3.amsl.com (Postfix) with ESMTP id 42CA63A659B for ; Mon, 1 Feb 2010 10:11:10 -0800 (PST) Received: by yxe4 with SMTP id 4so4068732yxe.32 for ; Mon, 01 Feb 2010 10:11:41 -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=Sg+Z4f7eKrTxbjSlv2AUD4NOW2oBbFt785dpkvwtPWc=; b=JSiJJQRzQ51AeYktQbeTZbxOrB0BtAW4OirOMQrHsjazmmmBYP54PC9ycpPNvKWTGI gtRCJImYx9OCd5Vq0ADHpIu1ItOXFM31jf9tvSgglNBiPnd65NhMz4d2k+T5JFZWL5Ls EOSrDDROtW7Ha3VPohOJACHguIwXHUnn3D3zk= 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=Gi4oGSkYfD21tDdKNIpNfWhv9mVQOqaiu+4roB4lXwwzZQ2rPH8OtxzR2qDbv10e9X nWTVXsefaod04rvuBuWsQvFJ9oTNr0CByPA1ucb5o0CRqScYRXgMR+DfwJb5hTfIFaen BaIJIW6B1hGTc7sChDMPviVmRRIdedw7EIv48= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.150.76.4 with SMTP id y4mr6863515yba.56.1265047901673; Mon, 01 Feb 2010 10:11:41 -0800 (PST) In-Reply-To: References: <201002010052.45922.richard.alimi@yale.edu> Date: Mon, 1 Feb 2010 13:11:41 -0500 X-Google-Sender-Auth: 74d6d24959c75a16 Message-ID: <8b2769931002011011gd4b09eat8d8d32dabcabf4f7@mail.gmail.com> From: "David A. Bryan" To: Wesley Leggette Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ext@core3.amsl.com, 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 18:11:12 -0000 Hi Wesley, A little bit off-topic, but sort of wanted to close loop on this topic. I think I understand what might have been a bit confusing about DECADE to you (and likely others) after reading your post. Unfortunately, now I'm a bit confused on what you are thinking about for this other group/proposal you mentioned. You mentioned a set of primitives in a storage protocol that would allow you to build a distributed file system. I guess my question is how this differs from NFS? Would the idea be that once you built this new set of primitives, NFS (and other things) could be built on top? If so, what applications (other than NFS, and maybe an implementation of whatever DECADE ends up being, I suppose) are you imagining such a protocol being used to implement? Thanks, David On Mon, Feb 1, 2010 at 12:35 PM, Wesley Leggette wrote: > > > > On 1/31/10 23:52, "Richard Alimi" wrote: > > >> >> I do realize that you are asking these questions in the context of a mor= e >> general distributed storage protocol, and that my answers are focused on= the >> use cases for DECADE. =A0I'm basically trying to illustrate how much sim= pler the >> protocol design can be with our original goal. > > I agree that a simple WORM system for P2P application-specific object > storage is much simpler to design. I'm glad to see that the scope and use > cases are going to be constrained as, yes, my point was that to not limit > the scope would would vastly complicate the requirements. > > What I think is interesting is that this is really meant as an in-network > storage for application-specific use. This is to say, while it is meant f= or > generic storage, it is not meant for generic cross-application *access*. > After realizing this, looking back over the use cases, they were a lot mo= re > clear to me. > > I've come up with the following analogy which has helped me to understand > the scope of DECADE. While I don't have any more specific comments, I sha= re > it here in the hopes of helping anyone else who is similarly confused: > > I now view the scope of DECADE as a sort of "one-way" approach that is > counter-intuitive when you think of it in terms of network storage protoc= ols > such as CIFS, WebDAV, and NFS, which all have a fixed data model (the "fi= le > system paradigm") and are meant for various clients to be able to underst= and > what the data is to some degree (as, at least, files, if not the format o= f > the files themselves). > > When you think of this in terms of more general "cloud storage" such as > Amazon S3, the picture becomes a bit clearer. In that sort of system, the > point isn't to define a data model for client interoperability, just to > provide a shared mechanism for storing data. It is up to the application > written on top to interpret how the data fits together when it is accesse= d. > > This is probably all very obvious to most of you, of course, but as P2P a= nd > "cloud storage" is still fairly new, it's probably worth mentioning at so= me > level. > > >>> 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 >> :) > > I'll make sure to keep this list informed. > > I should note that we fully embrace the sort of "object-based", > "no-paradigm" storage DECADE is all about, but my goal with another worki= ng > group would be to build a slightly more complicated base storage protocol > which would allow vendors to build (or simulate) more traditional access > patterns like "file system" and "block device" on top of it. Not the scop= e > of DECADE, but that is fine. > > > Wesley Leggette > Cleversafe, Inc. > > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > From wleggette@cleversafe.com Mon Feb 1 11:52:26 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 F20743A6A39 for ; Mon, 1 Feb 2010 11:52:25 -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 OHP2dqPA79Mt for ; Mon, 1 Feb 2010 11:52:24 -0800 (PST) Received: from p01c12o149.mxlogic.net (p01c12o149.mxlogic.net [208.65.145.72]) by core3.amsl.com (Postfix) with ESMTP id 48E443A698F for ; Mon, 1 Feb 2010 11:52:24 -0800 (PST) Received: from unknown [216.166.12.32] (EHLO p01c12o149.mxlogic.net) by p01c12o149.mxlogic.net(mxl_mta-6.5.0-0) with ESMTP id c11376b4.c5450b90.16518.00-412.35970.p01c12o149.mxlogic.net (envelope-from ); Mon, 01 Feb 2010 12:53:00 -0700 (MST) X-MXL-Hash: 4b67311c58a33611-c04bc69a99b97d8c3a5207b4c69738d92ffa562a Received: from unknown [216.166.12.32] by p01c12o149.mxlogic.net(mxl_mta-6.5.0-0) with SMTP id 901376b4.0.8618.00-015.35732.p01c12o149.mxlogic.net (envelope-from ); Mon, 01 Feb 2010 12:52:43 -0700 (MST) X-MXL-Hash: 4b67310b35739107-18f9945912285ccf445ffbcd84fb38ffddc43dd8 Received: from AUSP01VMBX09.collaborationhost.net ([10.2.8.161]) by AUSP01MHUB02.collaborationhost.net ([10.2.8.26]) with mapi; Mon, 1 Feb 2010 13:51:57 -0600 From: Wesley Leggette To: "David A. Bryan" Date: Mon, 1 Feb 2010 13:51:55 -0600 Thread-Topic: [decade] Updated DECADE Charter Thread-Index: Acqjayp3MiNRyKgpSiiNfc0/zOQR3wADNcKt Message-ID: In-Reply-To: <8b2769931002011011gd4b09eat8d8d32dabcabf4f7@mail.gmail.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.32] X-AnalysisOut: [v=1.0 c=1 a=zbe46bahRtDx8aUBN1lPzQ==:17 a=NJsBzmE2AAAA:8 a] X-AnalysisOut: [=DaIsx_ftaKX2P_60NxoA:9 a=XV2Fw8iXUNZa2NYxoZYA:7 a=7SYPvs5] X-AnalysisOut: [qzDLU7HeU8rmlubKKPkQA:4 a=jMc1ltSJCucA:10] Cc: "ext@core3.amsl.com" , 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 19:52:26 -0000 On 2/1/10 12:11, "David A. Bryan" wrote: > Hi Wesley, >=20 > A little bit off-topic, but sort of wanted to close loop on this topic. >=20 > I think I understand what might have been a bit confusing about DECADE > to you (and likely others) after reading your post. >=20 > Unfortunately, now I'm a bit confused on what you are thinking about > for this other group/proposal you mentioned. You mentioned a set of > primitives in a storage protocol that would allow you to build a > distributed file system. I guess my question is how this differs from > NFS? Would the idea be that once you built this new set of primitives, > NFS (and other things) could be built on top? If so, what applications > (other than NFS, and maybe an implementation of whatever DECADE ends > up being, I suppose) are you imagining such a protocol being used to > implement? Right, exactly. NFS is meant to be a "file system" protocol, and as such ha= s specific semantics implicit in that. For example, when you write a file, th= e linking of the file to the directory happens for you. File renames and deletes are atomic. For this stuff to occur, you need to perform locking or transactions (eithe= r one or a combination of both will generally work). Thus, CIFS and NFS (and WebDAV) work fine when the "access point" (the NFS server) is a single system, because it can perform the locks internally. Now, let's say that you want to have multiple access points. You want to allow file creates and deletes (which require directory metadata changes) simultaneously on the different systems. They still need to perform locking or transactions (so that creating, renaming, or deleting a file works correctly), so they need to cooperate to do this. pNFS nominally does this, but it does not seem to (unless I am missing something) define the locking mechanism (presumably some server), so interoperability (between servers, not between clients) is affected. Further, pNFS does handle in a form a "distributed file system" protocol (and the interoperability stuff is easily addressed), but what if you wante= d something else? What about block storage? What about distributed queue and message services? What about a distributed database? What about a object storage systems where the server assigns the object name for either content addressable storage or to make lookups faster? And what about handling replication, multiple access points, and what if you want to federate the storage to increase scalability (maybe a protocol that allows indirection between the object name and the remote address where the object is accessible from -- much like P2P systems do today)? In any distributed system, you're not going to get atomic operations, of course. But if the goal is to write some sort of application that will mimi= c other storage paradigms (block, file system, queues) there are typically a fairly small set of primitive guarantees that you need. If there is a general storage protocol that allows you to store data and provides some basic distributed computing primitives, that gives you a lot of flexibility and provides a platform on which higher-level protocols could be written. Wesley Leggette From melodysong@huawei.com Tue Feb 2 01:41: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 7605928C22B for ; Tue, 2 Feb 2010 01:41:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[AWL=0.960, 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 G4zBTjl9vTpr for ; Tue, 2 Feb 2010 01:41:44 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 45F6228C163 for ; Tue, 2 Feb 2010 01:41:44 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KX700JFAKAG6M@szxga04-in.huawei.com> for decade@ietf.org; Tue, 02 Feb 2010 17:42:16 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KX70048SKAG5I@szxga04-in.huawei.com> for decade@ietf.org; Tue, 02 Feb 2010 17:42:16 +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 <0KX7009WYKACMJ@szxml04-in.huawei.com> for decade@ietf.org; Tue, 02 Feb 2010 17:42:16 +0800 (CST) Date: Tue, 02 Feb 2010 17:42:14 +0800 From: Song Haibin In-reply-to: <6F0E7A7C-14D6-4C09-83EE-9F2B5CBAD132@nokia.com> To: 'Lars Eggert' , 'Richard Alimi' Message-id: <00de01caa3ec$00565e30$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: AcqjKGMXT3WB6nj9QrqDXBLRmMlNSQAuGa9Q 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, 02 Feb 2010 09:41:45 -0000 Hi Lars, I can guess the only difference between us is whether we need a separate control protocol or extend/configure the existing protocols such like NFS or WebDAV. My understanding is that we have many storage access protocols like NFS and WebDAV, as well as others protocols mentioned in my last email (http://www.ietf.org/mail-archive/web/decade/current/msg00147.html) such as SMB, NetWare Core Protocol (NCP), AFP and QFileSvr.400. It is good to reuse the capabilities defined in these protocols whenever possible. However, it is not wise to extend each protocol to solve the same problem in DECADE. > I can equally well envision an outcome where the DECADE > effort results in a BCP that says "here is how you configure > one or more NFS (or WebDAV) servers for caching media chunks, > and here's how you'd implement cache access in a P2P client." > In other words, there wouldn't be a separate protocol but > "just" configuration and practices of how to use NFS or > WebDAV for what's needed for this deployment case. It's beyond configuration in my mind. DECADE would be applied to multiple underlying protocols. They should understand the same resource/access control information in the same way. That's what a standard protocol does. BR, Haibin > -----Original Message----- > From: decade-bounces@ietf.org > [mailto:decade-bounces@ietf.org] On Behalf Of Lars Eggert > Sent: Monday, February 01, 2010 6:21 PM > To: Richard Alimi > Cc: decade@ietf.org > Subject: Re: [decade] Updated DECADE Charter > > Hi, > > On 2010-2-1, at 6:25, Richard Alimi wrote: > > 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. > > there's an assumption here that DECADE will result in a > separate protocol, potentially layered in top of existing > protocols like NFS or WebDAV. Why are we already convinced > that this is what the design would look like? > > I can equally well envision an outcome where the DECADE > effort results in a BCP that says "here is how you configure > one or more NFS (or WebDAV) servers for caching media chunks, > and here's how you'd implement cache access in a P2P client." > In other words, there wouldn't be a separate protocol but > "just" configuration and practices of how to use NFS or > WebDAV for what's needed for this deployment case. > > > 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. > > Right. This is similar to what I had as a design counterexample above. > > > - 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. > > From what I've seen, this step (DECADE needing to be a > separate protocol) is not sufficiently motivated. > > > 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? > > Not at all. I'm saying that we have successful storage > protocols (NFS, WebDAV) and it's unclear to me that we need a > third protocol just for this deployment scenario. I simply > haven't seen a conclusive argument for it. > > Lars > > > From lars.eggert@nokia.com Tue Feb 2 01:51:26 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 C15C528C23E for ; Tue, 2 Feb 2010 01:51:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, 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 Bs9sBOTxg3OB for ; Tue, 2 Feb 2010 01:51:26 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id B695128C0F3 for ; Tue, 2 Feb 2010 01:51:25 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o129pnrB029628; Tue, 2 Feb 2010 11:51:58 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Feb 2010 11:51:44 +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); Tue, 2 Feb 2010 11:51:44 +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 o129pfKc022772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Feb 2010 11:51:41 +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-8--965713946; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <00de01caa3ec$00565e30$310ca40a@china.huawei.com> Date: Tue, 2 Feb 2010 11:51:34 +0200 Message-Id: <85D75BB1-4FB4-4982-9626-2E4A1F7F492C@nokia.com> References: <00de01caa3ec$00565e30$310ca40a@china.huawei.com> To: Song Haibin 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]); Tue, 02 Feb 2010 11:51:35 +0200 (EET) X-OriginalArrivalTime: 02 Feb 2010 09:51:44.0261 (UTC) FILETIME=[53D64B50:01CAA3ED] 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: Tue, 02 Feb 2010 09:51:26 -0000 --Apple-Mail-8--965713946 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-2-2, at 11:42, Song Haibin wrote: > It's beyond configuration in my mind. DECADE would be applied to = multiple > underlying protocols. They should understand the same resource/access > control information in the same way. That's what a standard protocol = does. why would DECADE be applied to multiple underlying protocols; where is = the benefit? IMO you analyze them all and pick the one with the best = match for your deployment case. Then you decide whether you can get by = with scenario-speficif usage guidelines, need small extensions, or need = to layer something on top. Lars= --Apple-Mail-8--965713946 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 MQ8XDTEwMDIwMjA5NTEzNVowIwYJKoZIhvcNAQkEMRYEFOhmuDd9GXndQIl7X/gpMJ8NrA1TMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQAOs2xZHakMmy8DAErl4gbdcYT9W0rSDidTaJi1YDqIqPfOvEm/xZSmEMjE6H7+JmoMWUaL wdqiD0gyNg/BZtwSyX1NBJMlu4RcPqBwQu/N7dk7aCC0VAF50ieEFQzI2r2omFtER4MdDsdKXKog YNuRqJ+sOFYib+5nCCbpe2ESFjXvmqbDA0t24pMr69r6KKBwxGC0YWMjtOsM25Vb+AjdH+lv8IOK tJ2xhy7bOt0S4+t9MQP80nsuja6lllOznMZlfvpH3DTHHYw5EdQ6O19sffowjnOpB/YTg2AIJfwI o6p9loUU2ODTJrfkbeHPoDnL28gCBgKAGsTn8/J/vFYAAAAAAAAA --Apple-Mail-8--965713946-- From melodysong@huawei.com Tue Feb 2 08:27: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 5AB3128C0F5 for ; Tue, 2 Feb 2010 08:27:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPnlJPXUCcgE for ; Tue, 2 Feb 2010 08:27:53 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 6968E3A69A6 for ; Tue, 2 Feb 2010 08:27:51 -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 <0KX800GCM33782@szxga01-in.huawei.com> for decade@ietf.org; Wed, 03 Feb 2010 00:28:19 +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 <0KX800JAN337BN@szxga01-in.huawei.com> for decade@ietf.org; Wed, 03 Feb 2010 00:28:19 +0800 (CST) Received: from [172.24.1.6] (Forwarded-For: [117.88.123.197]) by szxmc03-in.huawei.com (mshttpd); Wed, 03 Feb 2010 00:28:19 +0800 Date: Wed, 03 Feb 2010 00:28:19 +0800 From: songhaibin 64081 In-reply-to: <85D75BB1-4FB4-4982-9626-2E4A1F7F492C@nokia.com> To: Lars Eggert Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: <00de01caa3ec$00565e30$310ca40a@china.huawei.com> <85D75BB1-4FB4-4982-9626-2E4A1F7F492C@nokia.com> 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, 02 Feb 2010 16:27:54 -0000 Hi Lars, > > On 2010-2-2, at 11:42, Song Haibin wrote: > > It's beyond configuration in my mind. DECADE would be applied to > multiple> underlying protocols. They should understand the same > resource/access> control information in the same way. That's what > a standard protocol does. > > why would DECADE be applied to multiple underlying protocols; > where is the benefit? IMO you analyze them all and pick the one > with the best match for your deployment case. Then you decide > whether you can get by with scenario-speficif usage guidelines, > need small extensions, or need to layer something on top. > Thanks for your response. Please allow me to give an simple example about why DECADE should be applied to multiple underlying protocols here. Applications such like PPLive may want to use in-network storage to accelerate their media distribution, they have already have a way to identify their media pieces, so what they want is to use a simple RTP protocol for the underlying data transport between clients and in-network storage and use anoth er protocol (DECADE) to do resource control. Of course, some other applications that already implemented NFS might want to use NFS as the underlying protocol. If we tie DECADE to a specific underlying protocol, there might need much changes for some applications to be modified to support it and it will be hard to intergrate with DECADE (so fail in the real world). BR, Haibin From richard.alimi@yale.edu Tue Feb 2 15:05:43 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 3223128C10A for ; Tue, 2 Feb 2010 15:05:43 -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 wqByTOnMtMUt for ; Tue, 2 Feb 2010 15:05:42 -0800 (PST) Received: from pantheon-po35.its.yale.edu (pantheon-po35.its.yale.edu [130.132.50.83]) by core3.amsl.com (Postfix) with ESMTP id C42183A689A for ; Tue, 2 Feb 2010 15:05:41 -0800 (PST) Received: from poweredge.velvetsea.net (adsl-75-31-8-3.dsl.wlfrct.sbcglobal.net [75.31.8.3]) (authenticated bits=0) by pantheon-po35.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id o12N6EWe021345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 2 Feb 2010 18:06:18 -0500 Received: from p4p-7.localnet (p4p-7.cs.yale.edu [128.36.233.97]) by poweredge.velvetsea.net (Postfix) with ESMTPSA id 9C93D42401C for ; Tue, 2 Feb 2010 18:06:14 -0500 (EST) From: Richard Alimi To: decade@ietf.org Date: Tue, 2 Feb 2010 18:06:13 -0500 User-Agent: KMail/1.12.4 (Linux/2.6.31-gentoo-r6; KDE/4.3.5; x86_64; ; ) References: <201001221658.24381.richard.alimi@yale.edu> In-Reply-To: <201001221658.24381.richard.alimi@yale.edu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002021806.13346.richard.alimi@yale.edu> X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) Subject: Re: [decade] Updated DECADE Charter (Revised) 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, 02 Feb 2010 23:05:43 -0000 Hi All, Thank you very much to all who have provided feedback and participated in the discussion on the proposed charter. Below is a revised version of the charter reflecting the discussion. We look forward to further comments and feedback. Thanks! ====================================================================== 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 existing and evolving protocols. 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). 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 currently lack capabilities for fine-grained access and resource control that are essential for today's advanced P2P applications. 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 policies 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 by other types of applications with similar protocol requirements. 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. 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. This group may also create a profile of necessary operations from an existing IETF protocol to reduce the complexity and software footprint of a DECADE-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: - Implementation of policies regarding 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 for data transport between P2P applications 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 ====================================================================== -- Richard Alimi Department of Computer Science Yale University From rpenno@juniper.net Tue Feb 2 15:48: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 E2B1D3A6B9D for ; Tue, 2 Feb 2010 15:48:54 -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 SOv48YLEWs3V for ; Tue, 2 Feb 2010 15:48:54 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 55C063A69C1 for ; Tue, 2 Feb 2010 15:48:53 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKS2i6DENTpeB0K9ak6otAzkIkDYBDXR1z@postini.com; Tue, 02 Feb 2010 15:49:34 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 2 Feb 2010 15:47:57 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 2 Feb 2010 18:47:57 -0500 From: Reinaldo Penno To: Richard Alimi , "decade@ietf.org" Date: Tue, 2 Feb 2010 18:47:55 -0500 Thread-Topic: [decade] Updated DECADE Charter (Revised) Thread-Index: AcqkXFjZ2Lg7jyg5RxWP+ZAW/gZEgwABcsXj Message-ID: In-Reply-To: <201002021806.13346.richard.alimi@yale.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [decade] Updated DECADE Charter (Revised) 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, 02 Feb 2010 23:48:55 -0000 Is it possible to have a step between these two where we narrow down the candidate protocols for the survey? It might be implied but the wording leaves the door open for a number of different protocols. If many protocols meet the requirements one way or another (tweaks, extensions, etc) the survey document might get quite intense. Therefore I would suggest some wording around a pre-selection. Another possibility is to have different surveys based on interest, volunteers, etc for each protocol. Then the pre-selection is done naturally= , if there is no interest in a certain protocol, then nobody will pick up the work.=20 Thanks, Reinaldo On 2/2/10 3:06 PM, "Richard Alimi" wrote: > - A requirements document. This document lists the requirements for the > in-network storage service (e.g., supported operations) and the protoco= l to > support it. >=20 > - A survey document. This document will survey existing related mechanism= s > and protocols (e.g., HTTP, NFS, and WebDAV), and evaluate their > applicability and effectiveness. From davidbryan@gmail.com Wed Feb 3 10:25:29 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 903E428C19D for ; Wed, 3 Feb 2010 10:25:29 -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 xxaVif1LjpLL for ; Wed, 3 Feb 2010 10:25:28 -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 AA5AB28C0E9 for ; Wed, 3 Feb 2010 10:25:28 -0800 (PST) Received: by gxk28 with SMTP id 28so1536063gxk.9 for ; Wed, 03 Feb 2010 10:26:07 -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=ZW8hPi+yz1ZMR4OUTqC3XD/DzxNEX9J6hGJKPnzqSXc=; b=hYSbW9daNeCJ+ZCtamF/XcU4kjg6pcQu9tzZxBZM486+2RrlIOuH6KouFYdjrAe8MI 4ullP9vlxpzBjq2r5U9y/oFNKC05ggNwWe38cZjW95etm+UpvkKuTLwt2NWj6B1kQRJx 2SnP4jqcPH14fdd2cTchf1U1VcN64mCB9bjXQ= 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=anaYYCWHAXitQuZxW8uWFx7b/gk8ZkDNwgFE4hbeZ/ww4AQGVq85k4p0LqPjLWUXIa SqYH7ch1f/agMbyPYrOhMIQHX1NaRccqkdpV/bI9ozw+dMn6xUG5m5g3aTBBy2TylU78 64kBuLKufHpJyD8V0sFaxb0B/i+5iS/7MII0s= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.151.21.1 with SMTP id y1mr382554ybi.100.1265221567719; Wed, 03 Feb 2010 10:26:07 -0800 (PST) In-Reply-To: References: <201002021806.13346.richard.alimi@yale.edu> Date: Wed, 3 Feb 2010 13:26:07 -0500 X-Google-Sender-Auth: d945a22ab2791964 Message-ID: <8b2769931002031026m299bec09k76fa2e931567919b@mail.gmail.com> From: "David A. Bryan" To: Reinaldo Penno Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "decade@ietf.org" Subject: Re: [decade] Updated DECADE Charter (Revised) 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, 03 Feb 2010 18:25:29 -0000 Is what you are suggesting by the different survey documents from various authors, almost something like "I like protocol AAA, so I write a document explaining why it meets the requirements better than XXX and YYY, and might revise it if someone also proposes ZZZ and I still think AAA is better"? It's an interesting approach. I understand what you are concerned about in terms of the growth of a survey document if there are many viable candidates, but a worry a bit that the approach I paraphrased above (which might not be quite what you are proposing, so forgive me if I put words in your mouth) starts to look a good deal like the proposals for various protocols making use of AAA. Now mind you this may be fine (we had something similar in P2PSIP with folks proposing SIP-based and binary encodings), but it seems like it more or less eliminates the survey document, and instead goes for a "battle of ideas" approach between possible protocols that could be used (and one could imagine a clean sheet proposal as well) I guess I'm a bit torn. If we have many proposals (so far I've only heard HTTP, WebDav and NFS seriously considered, so not sure I see the problem yet), the survey document could get large. I guess the big question is do we really think that a survey document can provide enough information to the group to determine which protocol to go with, divorced from actaually trying to design a use the protocol and see if the proposed protocol/extensions fit the requirements (modulo several iterations between those two that may be required.) David On Tue, Feb 2, 2010 at 6:47 PM, Reinaldo Penno wrote: > Is it possible to have a step between these two where we narrow down the > candidate protocols for the survey? It might be implied but the wording > leaves the door open for a number of different protocols. > > If many protocols meet the requirements one way or another (tweaks, > extensions, etc) the survey document might get quite intense. > > Therefore I would suggest some wording around a pre-selection. > > Another possibility is to have different surveys based on interest, > volunteers, etc for each protocol. Then the pre-selection is done natural= ly, > if there is no interest in a certain protocol, then nobody will pick up t= he > work. > > Thanks, > > Reinaldo > > > On 2/2/10 3:06 PM, "Richard Alimi" wrote: > >> - A requirements document. This document lists the requirements for the >> =A0 in-network storage service (e.g., supported operations) and the prot= ocol to >> =A0 support it. >> >> - A survey document. This document will survey existing related mechanis= ms >> =A0 and protocols (e.g., HTTP, NFS, and WebDAV), and evaluate their >> =A0 applicability and effectiveness. > > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > From rpenno@juniper.net Wed Feb 3 11:02:04 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 B373828C289 for ; Wed, 3 Feb 2010 11:02:04 -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 DvaQHlyk4223 for ; Wed, 3 Feb 2010 11:02:03 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id 3E64328C2B6 for ; Wed, 3 Feb 2010 10:55:12 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKS2nGupEwLGLfubtf7rxiB3qlPhI3KSbi@postini.com; Wed, 03 Feb 2010 10:55:57 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 3 Feb 2010 10:54:02 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 3 Feb 2010 13:54:01 -0500 From: Reinaldo Penno To: "David A. Bryan" Date: Wed, 3 Feb 2010 13:53:59 -0500 Thread-Topic: [decade] Updated DECADE Charter (Revised) Thread-Index: Acqk/lx0G+RrNPmJQzSm0io0wl5c1gAA+IDu Message-ID: In-Reply-To: <8b2769931002031026m299bec09k76fa2e931567919b@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.0.0.090609 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "decade@ietf.org" Subject: Re: [decade] Updated DECADE Charter (Revised) 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, 03 Feb 2010 19:02:04 -0000 Hello David, Comments inline...I shorten the thread a bit. On 2/3/10 10:26 AM, "David A. Bryan" wrote: >=20 > I guess I'm a bit torn. If we have many proposals (so far I've only > heard HTTP, WebDav and NFS seriously considered, so not sure I see the > problem yet), the survey document could get large. I guess the big > question is do we really think that a survey document can provide > enough information to the group to determine which protocol to go > with, divorced from actaually trying to design a use the protocol and > see if the proposed protocol/extensions fit the requirements (modulo > several iterations between those two that may be required.) I think we are in agreement here that this might be the crux of the issue. Survey, comparison, and other types of documents IMO have mixed results in the IETF. Some history on 'survey/evaluation' type documents that I followed: I remember the MIDCOM WG produced a lengthy 'strictly' technical evaluation of many candidates and the selected protocol was never really implemented b= y multiple vendors.=20 http://tools.ietf.org/html/rfc4097 I remember IPfix WG went down the same road but at some point changed gears and decided for most implemented and mature protocol. Multiple vendors toda= y implement IPFix. http://tools.ietf.org/html/rfc3955 There might be others. -Reinaldo >=20 > David >=20 > On Tue, Feb 2, 2010 at 6:47 PM, Reinaldo Penno wrote= : >> Is it possible to have a step between these two where we narrow down the >> candidate protocols for the survey? It might be implied but the wording >> leaves the door open for a number of different protocols. >>=20 >> If many protocols meet the requirements one way or another (tweaks, >> extensions, etc) the survey document might get quite intense. >>=20 >> Therefore I would suggest some wording around a pre-selection. >>=20 >> Another possibility is to have different surveys based on interest, >> volunteers, etc for each protocol. Then the pre-selection is done natura= lly, >> if there is no interest in a certain protocol, then nobody will pick up = the >> work. >>=20 >> Thanks, >>=20 >> Reinaldo >>=20 >>=20 >> On 2/2/10 3:06 PM, "Richard Alimi" wrote: >>=20 >>> - A requirements document. This document lists the requirements for the >>> =A0 in-network storage service (e.g., supported operations) and the pro= tocol >>> to >>> =A0 support it. >>>=20 >>> - A survey document. This document will survey existing related mechani= sms >>> =A0 and protocols (e.g., HTTP, NFS, and WebDAV), and evaluate their >>> =A0 applicability and effectiveness. >>=20 >> _______________________________________________ >> decade mailing list >> decade@ietf.org >> https://www.ietf.org/mailman/listinfo/decade >>=20 From strufe.pub@googlemail.com Thu Feb 4 23:21: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 3CD5B28C0F8 for ; Thu, 4 Feb 2010 23:21:40 -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 MGwabPHDj5TM for ; Thu, 4 Feb 2010 23:21:39 -0800 (PST) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id B3EC13A6EC5 for ; Thu, 4 Feb 2010 23:21:38 -0800 (PST) Received: by bwz19 with SMTP id 19so1170316bwz.28 for ; Thu, 04 Feb 2010 23:22:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=Gvlu/v6h5XpgNn9a95cP2jJmCCsNTHRU3U+QloyXrac=; b=DRuFrCFyxTKF21eAWSjn3f9GzU0YP63zW1NiUKZpJbdlumbhwZpTlWaFCi1G9ud887 DI9/VpH87UgA/f3v6ukZ70hc/Khc4CPWl8VRL65S+WVvMwu1CC48lHL5f7rhlQBFIPQW T3bRV7WXKtmCrCoI7CWtFhReSypB4LkiE18MQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=vp9FnnoJqxQAUtp1bVUe373SdgH7NYe6ezARzQpB7g3UOIa7zRhwgkEfmlQvPmBgNV b5O15ZbtC9ZlgY7F14gR7On4RR1Hq6oHC9BpA91E8GjhcQTjxFfLZ4LeolrwfNb+jDa3 Sxq1KlOaOwnhpEuh19hu4Vj51R0cz1yGqIFis= Received: by 10.204.8.5 with SMTP id f5mr229666bkf.59.1265354543984; Thu, 04 Feb 2010 23:22:23 -0800 (PST) Received: from ?130.83.163.202? ([130.83.163.202]) by mx.google.com with ESMTPS id 16sm462142bwz.7.2010.02.04.23.22.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 04 Feb 2010 23:22:23 -0800 (PST) Message-ID: <4B6BC72F.1090504@gmail.com> Date: Fri, 05 Feb 2010 08:22:23 +0100 From: Thorsten Strufe User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: decade@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: [decade] WoWMoM 2010 -- Call For Demos 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, 05 Feb 2010 07:21:40 -0000 [ apologies for crossposting ] WoWMoM 2010 11th IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks http://wowmom2010.netgroup.uniroma2.it/ 14-17 June 2010 Montreal, QC Canada --------------------------------------------------------------- CALL FOR DEMOS ============== The next IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks (WoWMoM 2010) will be the 11th event in its series. This symposium intends to provide a definitive forum for networking, software systems and multimedia research in the wireless/mobile area involving both computer science and electrical engineering communities. WoWMoM 2010 invites technical demonstrations showing innovative and original research in the areas of wireless, mobile, and multimedia networking as well as ubiquitous and pervasive systems. Submissions from both industry and academia are strongly encouraged. A BEST DEMO AWARD will be granted by WoWMoM 2010, based on the demos' innovation and technical contribution. SUBMISSIONS =========== Submissions should be emailed to the demo chairs hamouda (AT) ece.concordia.ca AND strufe (AT) cs.tu-darmstadt.de The submissions should include an extended abstract of up to two pages IEEE conference proceedings format. They should explicitly state what will be demonstrated to the WoWMoM audience, and how the attendees will be able to interact, enjoy, and experiment. The abstract should include a full list of authors with complete affiliations. Power and wireless Internet connectivity will be available at the venue. Please clearly state if any additional resources are needed or arrangements have to be made **in the email to the demo chairs** (not in the abstract). All submissions will undergo a rigorous review process, the extended abstracts of accepted demonstrations will be included in the proceedings of WoWMoM 2010. IMPORTANT DATES =============== Abstract submission deadline: 5 March 2010 Acceptance notification: 26 March 2010 Camera-ready submission: 20 April 2010 WoWMoM 2010: 14-17 June 2010 WoWMoM 2010 demo co-chairs Walaa Hamouda, Concordia University, Canada hamouda(AT)ece.concordia.ca Thorsten Strufe, TU-Darmstadt, Germany strufe(AT)cs.tu-darmstadt.de -- Thorsten Strufe Peer-to-Peer Networks Technische Universität Darmstadt http://www.p2p.tu-darmstadt.de/ From strufe@cs.tu-darmstadt.de Fri Feb 5 13:04: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 7C0F83A6819 for ; Fri, 5 Feb 2010 13:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 Uxp4GQXvBwDu for ; Fri, 5 Feb 2010 13:04:38 -0800 (PST) Received: from lnx500.hrz.tu-darmstadt.de (lnx500.hrz.tu-darmstadt.de [130.83.156.225]) by core3.amsl.com (Postfix) with ESMTP id 16CE93A67E4 for ; Fri, 5 Feb 2010 13:04:37 -0800 (PST) Received: from fire02.rbg.informatik.tu-darmstadt.de (fire02.rbg.informatik.tu-darmstadt.de [130.83.160.8]) by lnx500.hrz.tu-darmstadt.de (8.14.2/8.14.2/HRZ/PMX) with ESMTP id o15L5PLA002869 for ; Fri, 5 Feb 2010 22:05:26 +0100 (envelope-from strufe@cs.tu-darmstadt.de) Received: from mail.rbg.informatik.tu-darmstadt.de (localhost [127.0.0.1]) by fire02.rbg.informatik.tu-darmstadt.de (8.13.8+Sun/8.13.8) with ESMTP id o15L5Q0u028661 for ; Fri, 5 Feb 2010 22:05:26 +0100 (MET) Received: from [192.168.1.134] (ip-92-50-90-182.unitymediagroup.de [92.50.90.182]) (authenticated bits=0) by mail.rbg.informatik.tu-darmstadt.de (8.14.3/8.14.3) with ESMTP id o15L5QM3028654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 Feb 2010 22:05:26 +0100 (MET) Message-ID: <4B6C8811.9040102@cs.tu-darmstadt.de> Date: Fri, 05 Feb 2010 22:05:21 +0100 From: Thorsten Strufe User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: decade@ietf.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-PMX-TU: seen v0.99a by 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.5.205418 X-PMX-SPAMCHECK: outgoing mail Subject: [decade] WoWMoM 2010 -- Call For Demos 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, 05 Feb 2010 21:04:39 -0000 [ apologies for crossposting ] WoWMoM 2010 11th IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks http://wowmom2010.netgroup.uniroma2.it/ 14-17 June 2010 Montreal, QC Canada --------------------------------------------------------------- CALL FOR DEMOS ============== The next IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks (WoWMoM 2010) will be the 11th event in its series. This symposium intends to provide a definitive forum for networking, software systems and multimedia research in the wireless/mobile area involving both computer science and electrical engineering communities. WoWMoM 2010 invites technical demonstrations showing innovative and original research in the areas of wireless, mobile, and multimedia networking as well as ubiquitous and pervasive systems. Submissions from both industry and academia are strongly encouraged. A BEST DEMO AWARD will be granted by WoWMoM 2010, based on the demos' innovation and technical contribution. SUBMISSIONS =========== Submissions should be emailed to the demo chairs hamouda (AT) ece.concordia.ca AND strufe (AT) cs.tu-darmstadt.de The submissions should include an extended abstract of up to two pages IEEE conference proceedings format. They should explicitly state what will be demonstrated to the WoWMoM audience, and how the attendees will be able to interact, enjoy, and experiment. The abstract should include a full list of authors with complete affiliations. Power and wireless Internet connectivity will be available at the venue. Please clearly state if any additional resources are needed or arrangements have to be made **in the email to the demo chairs** (not in the abstract). All submissions will undergo a rigorous review process, the extended abstracts of accepted demonstrations will be included in the proceedings of WoWMoM 2010. IMPORTANT DATES =============== Abstract submission deadline: 5 March 2010 Acceptance notification: 26 March 2010 Camera-ready submission: 20 April 2010 WoWMoM 2010: 14-17 June 2010 WoWMoM 2010 demo co-chairs Walaa Hamouda, Concordia University, Canada hamouda(AT)ece.concordia.ca Thorsten Strufe, TU-Darmstadt, Germany strufe(AT)cs.tu-darmstadt.de -- Thorsten Strufe Peer-to-Peer Networks Technische Universität Darmstadt http://www.p2p.tu-darmstadt.de/ From melodysong@huawei.com Tue Feb 9 18:51:38 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 4E7E628C1D5 for ; Tue, 9 Feb 2010 18:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[AWL=-0.107, 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 KVKSBrLv10hH for ; Tue, 9 Feb 2010 18:51:37 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 2042128C1BF for ; Tue, 9 Feb 2010 18:51:37 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KXL00GYXUNNYC@szxga04-in.huawei.com> for decade@ietf.org; Wed, 10 Feb 2010 10:52:35 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KXL0081OUNN9W@szxga04-in.huawei.com> for decade@ietf.org; Wed, 10 Feb 2010 10:52:35 +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 <0KXL003D2UNJ2M@szxml04-in.huawei.com> for decade@ietf.org; Wed, 10 Feb 2010 10:52:35 +0800 (CST) Date: Wed, 10 Feb 2010 10:52:31 +0800 From: Song Haibin In-reply-to: To: 'Reinaldo Penno' , "'David A. Bryan'" Message-id: <00b001caa9fc$171f4b20$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=ISO-8859-1 Content-transfer-encoding: quoted-printable Thread-index: Acqk/lx0G+RrNPmJQzSm0io0wl5c1gAA+IDuAT2+/4A= Cc: decade@ietf.org Subject: Re: [decade] Updated DECADE Charter (Revised) 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, 10 Feb 2010 02:51:38 -0000 Hi Reinaldo, > -----Original Message----- > From: decade-bounces@ietf.org=20 > [mailto:decade-bounces@ietf.org] On Behalf Of Reinaldo Penno > Sent: Thursday, February 04, 2010 2:54 AM > To: David A. Bryan > Cc: decade@ietf.org > Subject: Re: [decade] Updated DECADE Charter (Revised) >=20 > Hello David, >=20 > Comments inline...I shorten the thread a bit. >=20 >=20 > On 2/3/10 10:26 AM, "David A. Bryan" wrote: >=20 > >=20 > > I guess I'm a bit torn. If we have many proposals (so far I've only=20 > > heard HTTP, WebDav and NFS seriously considered, so not=20 > sure I see the=20 > > problem yet), the survey document could get large. I guess the big=20 > > question is do we really think that a survey document can provide=20 > > enough information to the group to determine which protocol to go=20 > > with, divorced from actaually trying to design a use the=20 > protocol and=20 > > see if the proposed protocol/extensions fit the=20 > requirements (modulo=20 > > several iterations between those two that may be required.) >=20 > I think we are in agreement here that this might be the crux=20 > of the issue. > Survey, comparison, and other types of documents IMO have=20 > mixed results in the IETF. >=20 > Some history on 'survey/evaluation' type documents that I followed: >=20 > I remember the MIDCOM WG produced a lengthy 'strictly'=20 > technical evaluation of many candidates and the selected=20 > protocol was never really implemented by multiple vendors.=20 >=20 > http://tools.ietf.org/html/rfc4097 >=20 > I remember IPfix WG went down the same road but at some point=20 > changed gears and decided for most implemented and mature=20 > protocol. Multiple vendors today implement IPFix. >=20 > http://tools.ietf.org/html/rfc3955 >=20 Thanks for your information. That is actually why we would like to = choose a small number of widely implemented underlying protocols. And we describe that in the charter "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." >Is it possible to have a step between these two where we narrow down = the candidate protocols for the survey? It might be implied but the wording leaves the door open for a number of different protocols. >If many protocols meet the requirements one way or another (tweaks, extensions, etc) the survey document might get quite intense. >Therefore I would suggest some wording around a pre-selection. Yes, we would like to narrow down the candidate underlying protocols. We could consider HTTP, WebDAV and NFS first, and if we have other = underlying protocol as a consensus in the mailing list or at the meeting, we should incoporate it. In the charter, we said "NFS and WebDAV (might loose http here) are initial targets and others may be incorporated with WG = consensus." BR, Haibin > There might be others. >=20 > -Reinaldo >=20 >=20 > >=20 > > David > >=20 > > On Tue, Feb 2, 2010 at 6:47 PM, Reinaldo Penno=20 > wrote: > >> Is it possible to have a step between these two where we=20 > narrow down=20 > >> the candidate protocols for the survey? It might be=20 > implied but the=20 > >> wording leaves the door open for a number of different protocols. > >>=20 > >> If many protocols meet the requirements one way or another=20 > (tweaks,=20 > >> extensions, etc) the survey document might get quite intense. > >>=20 > >> Therefore I would suggest some wording around a pre-selection. > >>=20 > >> Another possibility is to have different surveys based on=20 > interest,=20 > >> volunteers, etc for each protocol. Then the pre-selection is done=20 > >> naturally, if there is no interest in a certain protocol,=20 > then nobody=20 > >> will pick up the work. > >>=20 > >> Thanks, > >>=20 > >> Reinaldo > >>=20 > >>=20 > >> On 2/2/10 3:06 PM, "Richard Alimi" wrote: > >>=20 > >>> - A requirements document. This document lists the=20 > requirements for=20 > >>> the > >>> =A0 in-network storage service (e.g., supported operations) and = the=20 > >>> protocol to > >>> =A0 support it. > >>>=20 > >>> - A survey document. This document will survey existing related=20 > >>> mechanisms > >>> =A0 and protocols (e.g., HTTP, NFS, and WebDAV), and evaluate = their > >>> =A0 applicability and effectiveness. > >>=20 > >> _______________________________________________ > >> decade mailing list > >> decade@ietf.org > >> https://www.ietf.org/mailman/listinfo/decade > >>=20 >=20 > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade >=20 From alexey.melnikov@isode.com Mon Feb 22 15:33:51 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 1B3BC28C200 for ; Mon, 22 Feb 2010 15:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 Bos1m2IgBeJN for ; Mon, 22 Feb 2010 15:33:50 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id E0E3A28C457 for ; Mon, 22 Feb 2010 15:33:46 -0800 (PST) Received: from [172.16.2.129] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 22 Feb 2010 23:35:45 +0000 Message-ID: <4B8314B6.3050301@isode.com> Date: Mon, 22 Feb 2010 23:35:18 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Richard Alimi References: <201001221658.24381.richard.alimi@yale.edu> <201002021806.13346.richard.alimi@yale.edu> In-Reply-To: <201002021806.13346.richard.alimi@yale.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: decade@ietf.org Subject: Re: [decade] Updated DECADE Charter (Revised) 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, 22 Feb 2010 23:33:51 -0000 Hi Richard, A minor comment (I am still thinking about the rest of the proposed Charter): Richard Alimi wrote: > Data storage, retrieval, and management may be provided by an existing IETF > protocol. 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. > I think the part "or create an Individual Submission if no active working group exists". As the sponsoring Area Director I would rather see such work be a product of this WG, as this makes judging consensus easier for me. So I would suggest rephrasing to read something like this: 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 IETF working groups, if such working group exist. >This group may also create a > profile of necessary operations from an existing IETF protocol to reduce the > complexity and software footprint of a DECADE-compliant implementation. > > From richard.alimi@gmail.com Mon Feb 22 15:45: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 87A5D28C479 for ; Mon, 22 Feb 2010 15:45:05 -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=[AWL=0.000, 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 Jkcjmr1Jusew for ; Mon, 22 Feb 2010 15:45:04 -0800 (PST) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 9BE0528C477 for ; Mon, 22 Feb 2010 15:45:04 -0800 (PST) Received: by fxm5 with SMTP id 5so3328544fxm.29 for ; Mon, 22 Feb 2010 15:47:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=4czsiaetc1yM7JtZhv+w/M8B1bmBqUTh7t2Y9zBUtHo=; b=oOuyU8hX8zTFXkz5l9A9tY9EPtysI4YbGLt/9DNdN02u0/YMeIxEwU2LHij45TQspJ 40n6Vkm37cclS4EmTNK6SZduWD2g/pBlI8JwAUE1UWpn6fpVuAMaad5W0ZAeGpSyjPgy xKu54gCD5VeEu8Im/EwjyUYJ762B1tDdgKEWI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=FiniVspCtAkKPRzQMu7BGMazF4sD4HICfjOL4bhJ7pHzPj0uKUVih4wlsUSPH3UoL1 yPPFepAVfhOl+/JYm2OO8tqT7BU/V9W9sC3bhLMpZGa8H0vHdXM5Dc90fmlb8yJkQnyJ GiVWu6eS/mT8tMhDCpjVcjyka/eNqPDTePVP8= Received: by 10.87.66.29 with SMTP id t29mr5770072fgk.49.1266882421595; Mon, 22 Feb 2010 15:47:01 -0800 (PST) Received: from p4p-7.localnet (p4p-7.cs.yale.edu [128.36.233.97]) by mx.google.com with ESMTPS id l12sm9516686fgb.27.2010.02.22.15.47.00 (version=SSLv3 cipher=RC4-MD5); Mon, 22 Feb 2010 15:47:00 -0800 (PST) Sender: Richard Alimi From: Richard Alimi To: Alexey Melnikov Date: Mon, 22 Feb 2010 18:46:56 -0500 User-Agent: KMail/1.13.0 (Linux/2.6.31-gentoo-r6; KDE/4.4.0; x86_64; ; ) References: <201001221658.24381.richard.alimi@yale.edu> <201002021806.13346.richard.alimi@yale.edu> <4B8314B6.3050301@isode.com> In-Reply-To: <4B8314B6.3050301@isode.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002221846.57815.richard.alimi@yale.edu> Cc: decade@ietf.org Subject: Re: [decade] Updated DECADE Charter (Revised) 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, 22 Feb 2010 23:51:18 -0000 Hi Alexey, Thanks for reading through. On Monday 22 February 2010 6:35:18 pm Alexey Melnikov wrote: > [...snip...] > > I think the part "or create an Individual Submission if no active > working group exists". As the sponsoring Area Director I would rather > see such work be a product of this WG, as this makes judging consensus > easier for me. > > So I would suggest rephrasing to read something like this: > > 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 IETF working groups, if such working > group exist. This makes sense and I've made the change locally. We can post a new draft within the next day or so incorporating additional changes (if there are any). Thanks! -- Richard Alimi Department of Computer Science Yale University From strufe.pub@googlemail.com Thu Feb 25 08:23:44 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 114433A83CF for ; Thu, 25 Feb 2010 08:23:44 -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 TfF3v6WCZN+V for ; Thu, 25 Feb 2010 08:23:42 -0800 (PST) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by core3.amsl.com (Postfix) with ESMTP id 12BC93A86DE for ; Thu, 25 Feb 2010 08:23:41 -0800 (PST) Received: by bwz3 with SMTP id 3so4694313bwz.29 for ; Thu, 25 Feb 2010 08:25:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=Gvlu/v6h5XpgNn9a95cP2jJmCCsNTHRU3U+QloyXrac=; b=jtRllN4Wzxyh7pOQKmYcUVsSnKFDF9xU/aZn1cc+4riR1XEqepRFasXrUfZw+TpN93 KGxlLx6lXJOwjKqpVfuUPP0aFSirrHAKONylpmjVq33srNhXKhqsHKbVxeD5AoYGRULW TjwoLiqcGEXReQJ/OAbyj37pI6U8ssYBo7VaI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=hof5+juSnUgOrAgpnCojq+jvinGbmepcEDCN53Eyud8umCDA1i5IfC5jAff6szW0hr P3K9wvyov6MS6pYxeV2J73HrD0F1XrZMhT7DEgaOdjaojfPqkRbwtE0v1nYm2XBo6V+5 Ff4DK91s+Qi6pAIwZCqIDEuDQ8ExzO6AZU9WM= Received: by 10.204.10.142 with SMTP id p14mr715933bkp.160.1267115149551; Thu, 25 Feb 2010 08:25:49 -0800 (PST) Received: from ?130.83.163.198? ([130.83.163.198]) by mx.google.com with ESMTPS id 14sm3605683bwz.10.2010.02.25.08.25.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 25 Feb 2010 08:25:49 -0800 (PST) Message-ID: <4B86A48B.9030807@gmail.com> Date: Thu, 25 Feb 2010 17:25:47 +0100 From: Thorsten Strufe User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: decade@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: [decade] A gentle reminder: WoWMoM 2010 -- Call For Demos 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, 25 Feb 2010 16:23:44 -0000 [ apologies for crossposting ] WoWMoM 2010 11th IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks http://wowmom2010.netgroup.uniroma2.it/ 14-17 June 2010 Montreal, QC Canada --------------------------------------------------------------- CALL FOR DEMOS ============== The next IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks (WoWMoM 2010) will be the 11th event in its series. This symposium intends to provide a definitive forum for networking, software systems and multimedia research in the wireless/mobile area involving both computer science and electrical engineering communities. WoWMoM 2010 invites technical demonstrations showing innovative and original research in the areas of wireless, mobile, and multimedia networking as well as ubiquitous and pervasive systems. Submissions from both industry and academia are strongly encouraged. A BEST DEMO AWARD will be granted by WoWMoM 2010, based on the demos' innovation and technical contribution. SUBMISSIONS =========== Submissions should be emailed to the demo chairs hamouda (AT) ece.concordia.ca AND strufe (AT) cs.tu-darmstadt.de The submissions should include an extended abstract of up to two pages IEEE conference proceedings format. They should explicitly state what will be demonstrated to the WoWMoM audience, and how the attendees will be able to interact, enjoy, and experiment. The abstract should include a full list of authors with complete affiliations. Power and wireless Internet connectivity will be available at the venue. Please clearly state if any additional resources are needed or arrangements have to be made **in the email to the demo chairs** (not in the abstract). All submissions will undergo a rigorous review process, the extended abstracts of accepted demonstrations will be included in the proceedings of WoWMoM 2010. IMPORTANT DATES =============== Abstract submission deadline: 5 March 2010 Acceptance notification: 26 March 2010 Camera-ready submission: 20 April 2010 WoWMoM 2010: 14-17 June 2010 WoWMoM 2010 demo co-chairs Walaa Hamouda, Concordia University, Canada hamouda(AT)ece.concordia.ca Thorsten Strufe, TU-Darmstadt, Germany strufe(AT)cs.tu-darmstadt.de -- Thorsten Strufe Peer-to-Peer Networks Technische Universität Darmstadt http://www.p2p.tu-darmstadt.de/