From melodysong@huawei.com Tue Sep 22 23:25:01 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6A5D3A682F for ; Tue, 22 Sep 2009 23:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[AWL=0.661, BAYES_20=-0.74] 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 EOZWJaHYpYA9 for ; Tue, 22 Sep 2009 23:25:00 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id B92643A67E6 for ; Tue, 22 Sep 2009 23:25:00 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQE008CZV7FHI@szxga03-in.huawei.com> for decade@ietf.org; Wed, 23 Sep 2009 14:26:03 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQE00M6GV7FPM@szxga03-in.huawei.com> for decade@ietf.org; Wed, 23 Sep 2009 14:26:03 +0800 (CST) Received: from s64081 ([10.164.12.29]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQE00240V7E1V@szxml04-in.huawei.com> for decade@ietf.org; Wed, 23 Sep 2009 14:26:03 +0800 (CST) Date: Wed, 23 Sep 2009 14:26:02 +0800 From: Song Haibin To: decade@ietf.org Message-id: <007101ca3c16$b942cbb0$1d0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Aco8Frj7rCvvfWYNSFulEL+zGQux4A== Subject: [decade] DECADE Charter discussion 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, 23 Sep 2009 06:25:01 -0000 Dear all, The following is the initial version of DECoupled Application Data Enroute (DECADE) charter for discussion. Thanks to many people (Richard Yang, Yushun, Rich Alimi, Ning Zong and many others) for their efforts to work it out. Please review and any comments are welcome! 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 utilize the specific P2P application protocols or acting as regular or super peers to provide in-network storage. But this approach poses challenges to both P2P cache vendors and P2P application developers. For P2P cache vendors, the challenges are to support both the evolving P2P application protocols, and the newly emerging protocols. For P2P applications, closed P2P caching systems limit P2P applications to effectively utilize in-network storage. 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. 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 system to (1) store and retrieve data, (2) specify access control on who can store into and retrieve from its allocated storage, and (3) indicate resource sharing policies. 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), and evaluate their applicability and effectiveness. - A request/response protocol for storing, retrieving, and managing content in the in-network storage. The protocol will have components to specify both access control and resource control policies. - 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. - Potential interactions between in-network storage operators and copyright holders of content. For example, one possibility is that that an in-network storage system may have system-wide ingress and egress filters to implement copyright related policies on storing or retrieving content in the in-network storage. But 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. Goals and Milestones: Aug 2010 Working Group Last Call for problem statement Nov 2010 Submit problem statement to IESG as Informational Nov 2010 Working Group Last Call for requirements document Apr 2011 Submit requirements document to IESG as Informational Aug 2011 Working Group Last Call for survey document Dec 2011 Working Group Last Call for in-network storage access protocol Apr 2012 Submit in-network storage access protocol to IESG as Proposed Standard Apr 2011 Submit survey document to IESG as informational Aug 2012 Dissolve or re-charter Best Regards, Haibin From abcdmatao@gmail.com Wed Sep 23 18:42:00 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF7693A69CD for ; Wed, 23 Sep 2009 18:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.612 X-Spam-Level: X-Spam-Status: No, score=-1.612 tagged_above=-999 required=5 tests=[AWL=0.986, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jnpJPBRWGOc for ; Wed, 23 Sep 2009 18:41:58 -0700 (PDT) Received: from mail-iw0-f186.google.com (mail-iw0-f186.google.com [209.85.223.186]) by core3.amsl.com (Postfix) with ESMTP id 315343A6767 for ; Wed, 23 Sep 2009 18:41:55 -0700 (PDT) Received: by iwn16 with SMTP id 16so772243iwn.29 for ; Wed, 23 Sep 2009 18:42:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=vSfzW5llsXJcD5TFYlEz1+vrFFk0j05gTUeMr/PoVpk=; b=MGFZHubiIxhPnEFhCEidqfIQvZJRgX3kLwuC5XPwu4eqleR//qZBQQpv881zWFBPhM Is8CtmejEPeD4rqKx35bBZrnAuXY+ZiHxe4pPvjxN+ZWcMUCFDNCMIIohck+P4dRMWcw J2Db8xQ5leAaKGgZ01hrlirOHf4gbvUn3cX2A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=NlYCB1NYXW1fYAeH8m3Ad+rI8Fn/CBM6p+r8zuR7Xx6j54K4INI2omt75aHujmhk6Z 8tMF3fuQY4NFJp36C8+q95zs9RTHnAZj/ilVUiq+a4x/HCDNwFgO/Q7q5a0lORuCaFcU J+vyAQEPhVMsO/ShF/uQT5F2z67B2DQ1/42cA= MIME-Version: 1.0 Received: by 10.231.62.137 with SMTP id x9mr6042514ibh.10.1253756579865; Wed, 23 Sep 2009 18:42:59 -0700 (PDT) Date: Thu, 24 Sep 2009 09:42:59 +0800 Message-ID: <99978d7d0909231842y14a0f6e7ke63ec22cf1976fa6@mail.gmail.com> From: Tao Ma To: Song Haibin , decade@ietf.org Content-Type: multipart/alternative; boundary=000e0cd4b32293e5b6047448f37f Cc: Chunhong Zhang Subject: Re: [decade] DECADE Charter discussion (Song Haibin) 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, 24 Sep 2009 01:42:00 -0000 --000e0cd4b32293e5b6047448f37f Content-Type: text/plain; charset=ISO-8859-1 Hi, Two questions: 1 Does the introduction of DECADE bring some changes to P2P application protocols? To my understanding, "a peer can choose to store content in the in-network storage, and direct other peers to retrieve from that location" means some changes to P2P application protocols. How does DECADE protocol and current P2P application protocol integrate or interact with each other? 2 I am curious about the so-called in-network storage system. Would DECADE WG add some description about the in-network storage system including its current situation and componets ? 0.1 cents Thank you:) Tao Ma Beijing University of Posts and Telecommunications, Mobile lIfe and New mEdia(MINE) Lab --000e0cd4b32293e5b6047448f37f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,
=A0=A0 Two questions:
1 Does the introduction of DECADE bring som= e changes to P2P application protocols? To my understanding,=A0 "a pee= r can choose to store content in the in-network storage, and direct other p= eers to retrieve from that location" means some changes to P2P applica= tion protocols. How does DECADE protocol and current P2P application protoc= ol integrate or interact with each other?
2 I am curious about the so-called in-network storage system. Would DECADE = WG add some description about=A0 the in-network storage system including it= s current situation and componets ?
0.1 cents
Thank you:)
=A0
Tao Ma
Beijing University of Posts and Telecommunications, Mobile lIfe a= nd New mEdia(MINE) Lab
--000e0cd4b32293e5b6047448f37f-- From davidbryan@gmail.com Wed Sep 23 19:29:19 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F0E73A67FF for ; Wed, 23 Sep 2009 19:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.573 X-Spam-Level: X-Spam-Status: No, score=-1.573 tagged_above=-999 required=5 tests=[AWL=0.404, 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 1xjL7ld6jl6Q for ; Wed, 23 Sep 2009 19:29:18 -0700 (PDT) Received: from mail-yw0-f188.google.com (mail-yw0-f188.google.com [209.85.211.188]) by core3.amsl.com (Postfix) with ESMTP id AFF1E3A67B8 for ; Wed, 23 Sep 2009 19:29:18 -0700 (PDT) Received: by ywh26 with SMTP id 26so668784ywh.29 for ; Wed, 23 Sep 2009 19:30:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=nr+mMIE+en0sEhEHWO7rqfYx1HdCHaMnIKKylqkAthI=; b=xMwEjDny7DBVSzim+kEDMFciZncwvjS18cuK5CU5+VF+KXpNv0sb9rP4GEpVVuSwCU 1WHucZ7+KYxIhtrNSCI5hw7Se++gdNDuZESuAglrdvEjmTw9xf8d0a1kEw4o7mJQsI6I 94iIvltFon/55n8PNSStsk07oJGuijdbmBGsE= 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; b=JzmUAETORmq9kod3BW1g9QtW8XdPgHOpaDS4ZDc9qKmP0aIsRXvexGYJI4ew6J6Q3E 2CEG29f9qsFppQ2ggVnv0sgwWyzwe//MfDidPa0ZHFlZAv6uKyEUKXYixG7uh2FXcWea LAcV4RWK3Zu551JW1awrYlN+4ccndDje8dl88= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.150.61.15 with SMTP id j15mr5320733yba.331.1253759423345; Wed, 23 Sep 2009 19:30:23 -0700 (PDT) In-Reply-To: <99978d7d0909231842y14a0f6e7ke63ec22cf1976fa6@mail.gmail.com> References: <99978d7d0909231842y14a0f6e7ke63ec22cf1976fa6@mail.gmail.com> Date: Wed, 23 Sep 2009 22:30:23 -0400 X-Google-Sender-Auth: 44925241b112447b Message-ID: <8b2769930909231930hb536754kee8616d8912ab4c7@mail.gmail.com> From: "David A. Bryan" To: Tao Ma Content-Type: text/plain; charset=ISO-8859-1 Cc: decade@ietf.org, Chunhong Zhang Subject: Re: [decade] DECADE Charter discussion (Song Haibin) 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, 24 Sep 2009 02:29:19 -0000 My thought is that an application or protocol may need some changes to take full advantage of DECADE, depending on what mechanisms may (or may not) exist in the application/protocol. For example, you will need a way to be provided a link as a response for a query. If the application already replies with a multi-protocol link (for example if you can reply with an HTTP link and some other protocol), you are probably in good shape. However, I suspect there are a large number of applications that may not behave this way today. For example, imagine a protocol where you search for a value, and it immediately returns the object (not a link/reference to it). In such a case, you would need a change. To phrase it another way, if you have two primitives like search (to locate the responsible location) and retrieve (to get the object), particularly if the location to retrieve from is given as a link, you may be able to work with DECADE with a fairly simple change. If it is an atomic "fetch" operation, you likely need a more radical change. Another consideration is the security mechanism. The application/protocol will need to be able to pass credentials to the person retrieving the object that will allow them to access the object stored in the in network storage. This feature may very well not be supported in the current protocol. I'm sure there are other changes that you may need, so yes, I expect most applications/protocol will need some modifications. I think once there is widespread deployment of DECADE servers, however, that the incentive of better performance (not to mention increased availability of resources when peers are offline) would be enough that at least some P2P applications would implement it. Do we have some P2P application developers here can comment? (I've implemented many P2P apps, but all for communications (VoIP, IM, etc), so we didn't really do object storage beyond rather small things like VM and configuration files...) David On Wed, Sep 23, 2009 at 9:42 PM, Tao Ma wrote: > Hi, > Two questions: > 1 Does the introduction of DECADE bring some changes to P2P application > protocols? To my understanding, "a peer can choose to store content in the > in-network storage, and direct other peers to retrieve from that location" > means some changes to P2P application protocols. How does DECADE protocol > and current P2P application protocol integrate or interact with each other? > 2 I am curious about the so-called in-network storage system. Would DECADE > WG add some description about the in-network storage system including its > current situation and componets ? > 0.1 cents > Thank you:) > > Tao Ma > Beijing University of Posts and Telecommunications, Mobile lIfe and New > mEdia(MINE) Lab > > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > > From abcdmatao@gmail.com Wed Sep 23 20:40:16 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3C2B3A67F2 for ; Wed, 23 Sep 2009 20:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.753 X-Spam-Level: X-Spam-Status: No, score=-1.753 tagged_above=-999 required=5 tests=[AWL=0.845, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfkYBkOfKbPW for ; Wed, 23 Sep 2009 20:40:14 -0700 (PDT) Received: from mail-iw0-f186.google.com (mail-iw0-f186.google.com [209.85.223.186]) by core3.amsl.com (Postfix) with ESMTP id 8C80B3A67D6 for ; Wed, 23 Sep 2009 20:40:14 -0700 (PDT) Received: by iwn16 with SMTP id 16so817212iwn.29 for ; Wed, 23 Sep 2009 20:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=8cEu9QekMkzuZaZ7aHSoH2nOzG47rTxKlAn0jOsC58A=; b=mxzj+EEbcm0+t8jsAp+w70iWfhFoaWwB6JvVD5zXznQPsVhhJAPkotVJpcPcSTqrmp lsEKHQA2AoBjLXeiui2cSwBS1wbg7yLVkmjt+vRgBE1LPu1xQzFHhZENMWN7I6pqCNuA 7hpBZv0/BxKKxi9OJ9l3GgZZz8uPuKSFURIOk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=K+0bd8Nkt7eCZdCJaeIWsqKa4H9hiItAGjzjhwOp2cTuVAhAOPwj8ljtM5vGYpqANl XBAP+3esCUENaNsKJA9xrJ6nrU23RHHyPk/sCAz06Pubmhilil5vMcuT+CV29CdO3qz7 BwStV7leY8Uh0cLegxZZqLq4xe16tLeaX4uO0= MIME-Version: 1.0 Received: by 10.231.42.150 with SMTP id s22mr6260279ibe.22.1253763679652; Wed, 23 Sep 2009 20:41:19 -0700 (PDT) In-Reply-To: <8b2769930909231930hb536754kee8616d8912ab4c7@mail.gmail.com> References: <99978d7d0909231842y14a0f6e7ke63ec22cf1976fa6@mail.gmail.com> <8b2769930909231930hb536754kee8616d8912ab4c7@mail.gmail.com> Date: Thu, 24 Sep 2009 11:41:19 +0800 Message-ID: <99978d7d0909232041r7872672ay64ab86f51b0de4c3@mail.gmail.com> From: Tao Ma To: "David A. Bryan" Content-Type: multipart/alternative; boundary=001517741a14c20ba204744a9aa2 Cc: decade@ietf.org, Chunhong Zhang Subject: Re: [decade] DECADE Charter discussion (Song Haibin) 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, 24 Sep 2009 03:40:16 -0000 --001517741a14c20ba204744a9aa2 Content-Type: text/plain; charset=ISO-8859-1 Hi, I think the least changes to most populalar P2P application should be a philosophy or principle of designing DECADE protocol. Thus, the analysis and evaluation of the future interaction with the current P2P application as David did in the mail would be necessary. Regards Tao Ma Beijing University of Posts and Telecommunications, Mobile lIfe and New mEdia(MINE) Lab 2009/9/24 David A. Bryan > My thought is that an application or protocol may need some changes to > take full advantage of DECADE, depending on what mechanisms may (or > may not) exist in the application/protocol. > > For example, you will need a way to be provided a link as a response > for a query. If the application already replies with a multi-protocol > link (for example if you can reply with an HTTP link and some other > protocol), you are probably in good shape. However, I suspect there > are a large number of applications that may not behave this way today. > > For example, imagine a protocol where you search for a value, and it > immediately returns the object (not a link/reference to it). In such a > case, you would need a change. To phrase it another way, if you have > two primitives like search (to locate the responsible location) and > retrieve (to get the object), particularly if the location to retrieve > from is given as a link, you may be able to work with DECADE with a > fairly simple change. If it is an atomic "fetch" operation, you likely > need a more radical change. > > Another consideration is the security mechanism. The > application/protocol will need to be able to pass credentials to the > person retrieving the object that will allow them to access the object > stored in the in network storage. This feature may very well not be > supported in the current protocol. > > I'm sure there are other changes that you may need, so yes, I expect > most applications/protocol will need some modifications. I think once > there is widespread deployment of DECADE servers, however, that the > incentive of better performance (not to mention increased availability > of resources when peers are offline) would be enough that at least > some P2P applications would implement it. > > Do we have some P2P application developers here can comment? (I've > implemented many P2P apps, but all for communications (VoIP, IM, etc), > so we didn't really do object storage beyond rather small things like > VM and configuration files...) > > David > > On Wed, Sep 23, 2009 at 9:42 PM, Tao Ma wrote: > > Hi, > > Two questions: > > 1 Does the introduction of DECADE bring some changes to P2P application > > protocols? To my understanding, "a peer can choose to store content in > the > > in-network storage, and direct other peers to retrieve from that > location" > > means some changes to P2P application protocols. How does DECADE protocol > > and current P2P application protocol integrate or interact with each > other? > > 2 I am curious about the so-called in-network storage system. Would > DECADE > > WG add some description about the in-network storage system including > its > > current situation and componets ? > > 0.1 cents > > Thank you:) > > > > Tao Ma > > Beijing University of Posts and Telecommunications, Mobile lIfe and New > > mEdia(MINE) Lab > > > > _______________________________________________ > > decade mailing list > > decade@ietf.org > > https://www.ietf.org/mailman/listinfo/decade > > > > > --001517741a14c20ba204744a9aa2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,
=A0=A0 I think the least changes to most populalar P2P application s= hould be a philosophy or principle of designing DECADE protocol. Thus,=A0 t= he analysis and evaluation of the future interaction with the current P2P a= pplication as David did in the mail would be necessary.
=A0=A0 Regards
Tao Ma
Beijing University of Posts and Telecommunicati= ons, Mobile lIfe and New mEdia(MINE) Lab

= 2009/9/24 David A. Bryan <dbryan@ethernot.org>
My thought is tha= t an application or protocol may need some changes to
take full advantage of DECADE, depending on what mechanisms may (or
may not) exist in the application/protocol.

For example, you will need a way to be provided a link as a response
for a query. If the application already replies with a multi-protocol
link (for example if you can reply with an HTTP link and some other
protocol), you are probably in good shape. However, I suspect there
are a large number of applications that may not behave this way today.

For example, imagine a protocol where you search for a value, and it
immediately returns the object (not a link/reference to it). In such a
case, you would need a change. To phrase it another way, if you have
two primitives like search (to locate the responsible location) and
retrieve (to get the object), particularly if the location to retrieve
from is given as a link, you may be able to work with DECADE with a
fairly simple change. If it is an atomic "fetch" operation, you l= ikely
need a more radical change.

Another consideration is the security mechanism. The
application/protocol will need to be able to pass credentials to the
person retrieving the object that will allow them to access the object
stored in the in network storage. This feature may very well not be
supported in the current protocol.

I'm sure there are other changes that you may need, so yes, I expect most applications/protocol will need some modifications. I think once
there is widespread deployment of DECADE servers, however, that the
incentive of better performance (not to mention increased availability
of resources when peers are offline) would be enough that at least
some P2P applications would implement it.

Do we have some P2P application developers here can comment? (I've
implemented many P2P apps, but all for communications (VoIP, IM, etc),
so we didn't really do object storage beyond rather small things like VM and configuration files...)

David

On Wed, Sep 23, 2009 at 9:42 PM, Tao Ma <abcdmatao@gmail.com> wrote:
> Hi,
> =A0 =A0Two questions:
> 1 Does the introduction of DECADE bring some changes to P2P applicatio= n
> protocols? To my understanding, =A0"a peer can choose to store co= ntent in the
> in-network storage, and direct other peers to retrieve from that locat= ion"
> means some changes to P2P application protocols. How does DECADE proto= col
> and current P2P application protocol integrate or interact with each o= ther?
> 2 I am curious about the so-called in-network storage system. Would DE= CADE
> WG add some description about =A0the in-network storage system includi= ng its
> current situation and componets ?
> 0.1 cents
> Thank you:)
>
> Tao Ma
> Beijing University of Posts and Telecommunications, Mobile lIfe and Ne= w
> mEdia(MINE) Lab
>
> _______________________________________________
> decade mailing list
> decade@ietf.org
> https://www.ietf.org/mailman/listinfo/decade
>
>

--001517741a14c20ba204744a9aa2-- From melodysong@huawei.com Wed Sep 23 20:50:21 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDA7A3A6A25 for ; Wed, 23 Sep 2009 20:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.008 X-Spam-Level: X-Spam-Status: No, score=0.008 tagged_above=-999 required=5 tests=[AWL=0.503, 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 ABOYBLU-HcLe for ; Wed, 23 Sep 2009 20:50:20 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 679E03A67F2 for ; Wed, 23 Sep 2009 20:50:20 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQG00B14IPDX2@szxga04-in.huawei.com> for decade@ietf.org; Thu, 24 Sep 2009 11:51:13 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQG0036LIPD6B@szxga04-in.huawei.com> for decade@ietf.org; Thu, 24 Sep 2009 11:51:13 +0800 (CST) Received: from s64081 ([10.164.12.29]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQG00BC9IPCDN@szxml06-in.huawei.com> for decade@ietf.org; Thu, 24 Sep 2009 11:51:13 +0800 (CST) Date: Thu, 24 Sep 2009 11:51:13 +0800 From: Song Haibin In-reply-to: <99978d7d0909232041r7872672ay64ab86f51b0de4c3@mail.gmail.com> To: 'Tao Ma' , "'David A. Bryan'" Message-id: <009b01ca3cca$43176ef0$1d0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Aco8yUSS24oTGf/NQqu8QrboHlVdhgAAGsAQ Cc: decade@ietf.org, 'Chunhong Zhang' Subject: Re: [decade] DECADE Charter discussion (Song Haibin) 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, 24 Sep 2009 03:50:21 -0000 Hi, Yes, there could be a little changes to the existing P2P applications to use DECADE as David said. That's also what one delivery document is going to do. > - An informational document describing the integration of DECADE with existing P2P applications (e.g., integration with Bittorrent). > Thanks! Haibin ________________________________ From: Tao Ma [mailto:abcdmatao@gmail.com] Sent: Thursday, September 24, 2009 11:41 AM To: David A. Bryan Cc: Song Haibin; decade@ietf.org; Chunhong Zhang Subject: Re: [decade] DECADE Charter discussion (Song Haibin) Hi, I think the least changes to most populalar P2P application should be a philosophy or principle of designing DECADE protocol. Thus, the analysis and evaluation of the future interaction with the current P2P application as David did in the mail would be necessary. Regards Tao Ma Beijing University of Posts and Telecommunications, Mobile lIfe and New mEdia(MINE) Lab 2009/9/24 David A. Bryan My thought is that an application or protocol may need some changes to take full advantage of DECADE, depending on what mechanisms may (or may not) exist in the application/protocol. For example, you will need a way to be provided a link as a response for a query. If the application already replies with a multi-protocol link (for example if you can reply with an HTTP link and some other protocol), you are probably in good shape. However, I suspect there are a large number of applications that may not behave this way today. For example, imagine a protocol where you search for a value, and it immediately returns the object (not a link/reference to it). In such a case, you would need a change. To phrase it another way, if you have two primitives like search (to locate the responsible location) and retrieve (to get the object), particularly if the location to retrieve from is given as a link, you may be able to work with DECADE with a fairly simple change. If it is an atomic "fetch" operation, you likely need a more radical change. Another consideration is the security mechanism. The application/protocol will need to be able to pass credentials to the person retrieving the object that will allow them to access the object stored in the in network storage. This feature may very well not be supported in the current protocol. I'm sure there are other changes that you may need, so yes, I expect most applications/protocol will need some modifications. I think once there is widespread deployment of DECADE servers, however, that the incentive of better performance (not to mention increased availability of resources when peers are offline) would be enough that at least some P2P applications would implement it. Do we have some P2P application developers here can comment? (I've implemented many P2P apps, but all for communications (VoIP, IM, etc), so we didn't really do object storage beyond rather small things like VM and configuration files...) David On Wed, Sep 23, 2009 at 9:42 PM, Tao Ma wrote: > Hi, > Two questions: > 1 Does the introduction of DECADE bring some changes to P2P application > protocols? To my understanding, "a peer can choose to store content in the > in-network storage, and direct other peers to retrieve from that location" > means some changes to P2P application protocols. How does DECADE protocol > and current P2P application protocol integrate or interact with each other? > 2 I am curious about the so-called in-network storage system. Would DECADE > WG add some description about the in-network storage system including its > current situation and componets ? > 0.1 cents > Thank you:) > > Tao Ma > Beijing University of Posts and Telecommunications, Mobile lIfe and New > mEdia(MINE) Lab > > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > > From melodysong@huawei.com Wed Sep 23 22:59:19 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 981D13A6807 for ; Wed, 23 Sep 2009 22:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.069 X-Spam-Level: X-Spam-Status: No, score=-1.069 tagged_above=-999 required=5 tests=[AWL=1.530, 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 iULfheWZj0RU for ; Wed, 23 Sep 2009 22:59:18 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 4DE1B3A67AB for ; Wed, 23 Sep 2009 22:59:18 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQG00AINOONXH@szxga04-in.huawei.com> for decade@ietf.org; Thu, 24 Sep 2009 14:00:23 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQG00HI8OONRR@szxga04-in.huawei.com> for decade@ietf.org; Thu, 24 Sep 2009 14:00:23 +0800 (CST) Received: from s64081 ([10.164.12.29]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQG00KY8OOM2R@szxml04-in.huawei.com> for decade@ietf.org; Thu, 24 Sep 2009 14:00:23 +0800 (CST) Date: Thu, 24 Sep 2009 14:00:22 +0800 From: Song Haibin In-reply-to: <009b01ca3cca$43176ef0$1d0ca40a@china.huawei.com> To: 'Tao Ma' Message-id: <009c01ca3cdc$4de7d0b0$1d0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Aco8yUSS24oTGf/NQqu8QrboHlVdhgAAGsAQAASJtPA= Cc: decade@ietf.org, 'Chunhong Zhang' Subject: Re: [decade] DECADE Charter discussion 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, 24 Sep 2009 05:59:19 -0000 I removed my name from the subject. Thanks! Haibin >-----Original Message----- >From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] >On Behalf Of Song Haibin >Sent: Thursday, September 24, 2009 11:51 AM >To: 'Tao Ma'; 'David A. Bryan' >Cc: decade@ietf.org; 'Chunhong Zhang' >Subject: Re: [decade] DECADE Charter discussion (Song Haibin) > >Hi, > >Yes, there could be a little changes to the existing P2P >applications to use DECADE as David said. That's also what one >delivery document is going to do. > >> >- An informational document describing the integration of >DECADE with existing P2P applications (e.g., integration with >Bittorrent). > > > >Thanks! >Haibin > > > > > > >________________________________ > > From: Tao Ma [mailto:abcdmatao@gmail.com] > Sent: Thursday, September 24, 2009 11:41 AM > To: David A. Bryan > Cc: Song Haibin; decade@ietf.org; Chunhong Zhang > Subject: Re: [decade] DECADE Charter discussion (Song Haibin) > > > Hi, > I think the least changes to most populalar P2P >application should be a philosophy or principle of designing >DECADE protocol. Thus, the analysis and evaluation of the >future interaction with the current P2P application as David >did in the mail would be necessary. > Regards > Tao Ma > Beijing University of Posts and Telecommunications, >Mobile lIfe and New mEdia(MINE) Lab > > > 2009/9/24 David A. Bryan > > > My thought is that an application or protocol >may need some changes to > take full advantage of DECADE, depending on >what mechanisms may (or > may not) exist in the application/protocol. > > For example, you will need a way to be provided >a link as a response > for a query. If the application already replies >with a multi-protocol > link (for example if you can reply with an HTTP >link and some other > protocol), you are probably in good shape. >However, I suspect there > are a large number of applications that may not >behave this way today. > > For example, imagine a protocol where you >search for a value, and it > immediately returns the object (not a >link/reference to it). >In such a > case, you would need a change. To phrase it >another way, if you have > two primitives like search (to locate the responsible >location) and > retrieve (to get the object), particularly if >the location to retrieve > from is given as a link, you may be able to >work with DECADE with a > fairly simple change. If it is an atomic >"fetch" operation, you likely > need a more radical change. > > Another consideration is the security mechanism. The > application/protocol will need to be able to >pass credentials to the > person retrieving the object that will allow >them to access the object > stored in the in network storage. This feature >may very well not be > supported in the current protocol. > > I'm sure there are other changes that you may >need, so yes, I expect > most applications/protocol will need some >modifications. I think once > there is widespread deployment of DECADE >servers, however, that the > incentive of better performance (not to mention >increased availability > of resources when peers are offline) would be >enough that at least > some P2P applications would implement it. > > Do we have some P2P application developers here >can comment? >(I've > implemented many P2P apps, but all for >communications (VoIP, IM, etc), > so we didn't really do object storage beyond >rather small things like > VM and configuration files...) > > David > > > On Wed, Sep 23, 2009 at 9:42 PM, Tao Ma > wrote: > > Hi, > > Two questions: > > 1 Does the introduction of DECADE bring some >changes to P2P application > > protocols? To my understanding, "a peer can >choose to store content in the > > in-network storage, and direct other peers to >retrieve from that location" > > means some changes to P2P application >protocols. How does DECADE protocol > > and current P2P application protocol >integrate or interact with each other? > > 2 I am curious about the so-called in-network >storage system. Would DECADE > > WG add some description about the in-network >storage system including its > > current situation and componets ? > > 0.1 cents > > Thank you:) > > > > Tao Ma > > Beijing University of Posts and >Telecommunications, Mobile lIfe and New > > mEdia(MINE) Lab > > > > > _______________________________________________ > > decade mailing list > > decade@ietf.org > > https://www.ietf.org/mailman/listinfo/decade > > > > > > > > >_______________________________________________ >decade mailing list >decade@ietf.org >https://www.ietf.org/mailman/listinfo/decade > From richard.alimi@yale.edu Thu Sep 24 06:45:48 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 447613A69E9 for ; Thu, 24 Sep 2009 06:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNOGLPJBkeaF for ; Thu, 24 Sep 2009 06:45:47 -0700 (PDT) Received: from pantheon-po32.its.yale.edu (pantheon-po32.its.yale.edu [130.132.50.88]) by core3.amsl.com (Postfix) with ESMTP id 458BE3A69D1 for ; Thu, 24 Sep 2009 06:45:47 -0700 (PDT) Received: from poweredge.velvetsea.net (adsl-76-211-180-1.dsl.wlfrct.sbcglobal.net [76.211.180.1]) (authenticated bits=0) by pantheon-po32.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id n8ODkUvj021645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 24 Sep 2009 09:46:33 -0400 Received: from ralimi.localnet (p4p-7.cs.yale.edu [128.36.233.97]) by poweredge.velvetsea.net (Postfix) with ESMTPSA id 06020424001; Thu, 24 Sep 2009 09:46:30 -0400 (EDT) From: Richard Alimi To: decade@ietf.org Date: Thu, 24 Sep 2009 09:46:29 -0400 User-Agent: KMail/1.12.1 (Linux/2.6.30-gentoo-r6; KDE/4.3.1; x86_64; ; ) References: <99978d7d0909231842y14a0f6e7ke63ec22cf1976fa6@mail.gmail.com> <8b2769930909231930hb536754kee8616d8912ab4c7@mail.gmail.com> In-Reply-To: <8b2769930909231930hb536754kee8616d8912ab4c7@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200909240946.29246.richard.alimi@yale.edu> X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) Cc: Tao Ma , Chunhong Zhang Subject: Re: [decade] DECADE Charter discussion (Song Haibin) 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, 24 Sep 2009 13:45:48 -0000 Hi David, > Do we have some P2P application developers here can comment? (I've > implemented many P2P apps, but all for communications (VoIP, IM, etc), > so we didn't really do object storage beyond rather small things like > VM and configuration files...) While I wouldn't classify myself as a "P2P application developer", I can comment a bit on how we accomplished our integration of BitTorrent with our Sailor work. This is certainly not the only way it can be done, but I'm mentioning it to give some intuition. We integrated with Vuze (formerly Azureus) as a plugin, so some of our implementation reflects what could be reasonably accomplished within Vuze's Plugin API (e.g., we avoided changing formats for existing messages). After the initial handshake, peer A and B send each other a message identifying the name/address and an identifier which uniquely identifies the in-network storage used by a peer. If a peer does not receive the additional handshake message from the other peer, it assumes the other peer does not support the extension, and falls back to the traditional BitTorrent protocol. For the remainder, lets assume both peers support in-network storage. Note that they may or may not have access to in-network storage of their own, but they understand the protocol. At a high-level, we added two messages: 1) slr-bt-request: This is a request for a block from peer A to peer B that includes an access token for A's in-network storage. Peer B may use the token to directly store the block in A's storage. We use this message instead of BitTorrent's 'request' message. 2) slr-bt-direct: This is used by peer B to indicate to peer A where to retrieve the block. If peer B is using its own in-network storage, then it includes an access token, and peer A downloads data from B's in-network storage into its own storage, and then retrieves the block. If B is not using its own in-network storage, then B stores the block in to A's storage (using the token received from A), and A retrieves it from there. There are a couple more specifics here that handle the cases when one or both of the peers do not have access to in-network storage themselves (e.g., if their ISP has not yet offered the service). If you are interested in the details, I'd be happy to fill them in. I left them out for now since the details may not be constructive at this point in the DECADE discussion :) -- Richard Alimi Department of Computer Science Yale University From davidbryan@gmail.com Thu Sep 24 07:38:08 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25B3A3A695A for ; Thu, 24 Sep 2009 07:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.631 X-Spam-Level: X-Spam-Status: No, score=-1.631 tagged_above=-999 required=5 tests=[AWL=0.346, 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 zKgWWumgjyjS for ; Thu, 24 Sep 2009 07:38:07 -0700 (PDT) Received: from mail-yw0-f188.google.com (mail-yw0-f188.google.com [209.85.211.188]) by core3.amsl.com (Postfix) with ESMTP id 2B1F53A69F4 for ; Thu, 24 Sep 2009 07:38:07 -0700 (PDT) Received: by ywh26 with SMTP id 26so78606ywh.29 for ; Thu, 24 Sep 2009 07:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=CGlcQnIZ35bOyolrsLHGtNhxqXUwg1lBHPf6ujkNwOA=; b=sccL+MgTysIjnbM4Ps9K3Cu98MdBTNeKcUw5C4s2n7ll1Wn55dpCajG5KfO04SyDE6 pKjpGVVNXgsE7+Up+DcguZZEN+xHIw2vAJ2lvajmPa9sGOGDcE2pA6vtTE1Ads9fAijg LYXVBndR5GH3hCX4cTbtRgiaDEXBuP+91yGrA= 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; b=B39HXJML68s0B609DTgMDbIonHybnFCVt3hv4sR/v5iUrYzr8RDxauDVmOf5a4A47q l1UetYtxRMlxPaWSULBU7svmsuQ/MXxQn587qS9TLp2K6lTa8wNuAAe6ZTqdiS9gPwUd //U721EzVVKS8IMjVGp2wgVoiVkQI9D7QNuXg= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.150.87.12 with SMTP id k12mr51093ybb.320.1253802790100; Thu, 24 Sep 2009 07:33:10 -0700 (PDT) In-Reply-To: <200909240946.29246.richard.alimi@yale.edu> References: <99978d7d0909231842y14a0f6e7ke63ec22cf1976fa6@mail.gmail.com> <8b2769930909231930hb536754kee8616d8912ab4c7@mail.gmail.com> <200909240946.29246.richard.alimi@yale.edu> Date: Thu, 24 Sep 2009 10:33:10 -0400 X-Google-Sender-Auth: a912789c69bd566b Message-ID: <8b2769930909240733m5ce84939h9f320c4e80570ed4@mail.gmail.com> From: "David A. Bryan" To: Richard Alimi Content-Type: text/plain; charset=ISO-8859-1 Cc: Tao Ma , decade@ietf.org, Chunhong Zhang Subject: Re: [decade] DECADE Charter discussion (Song Haibin) 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, 24 Sep 2009 14:38:08 -0000 Thanks, Richard. I think this really useful to see -- a bit of a twist on what I was thinking. I think there are likely to be a number of clever ways (similar to this) that could be used to integrate existing applications with DECADE, and one hopes, make it as painless of a process for the developers as possible -- the less pain, the greater the adoption. David On Thu, Sep 24, 2009 at 9:46 AM, Richard Alimi wrote: > Hi David, > >> Do we have some P2P application developers here can comment? (I've >> implemented many P2P apps, but all for communications (VoIP, IM, etc), >> so we didn't really do object storage beyond rather small things like >> VM and configuration files...) > > While I wouldn't classify myself as a "P2P application developer", I can > comment a bit on how we accomplished our integration of BitTorrent with our > Sailor work. This is certainly not the only way it can be done, but I'm > mentioning it to give some intuition. We integrated with Vuze (formerly > Azureus) as a plugin, so some of our implementation reflects what could be > reasonably accomplished within Vuze's Plugin API (e.g., we avoided changing > formats for existing messages). > > After the initial handshake, peer A and B send each other a message > identifying the name/address and an identifier which uniquely identifies the > in-network storage used by a peer. If a peer does not receive the additional > handshake message from the other peer, it assumes the other peer does not > support the extension, and falls back to the traditional BitTorrent protocol. > For the remainder, lets assume both peers support in-network storage. Note > that they may or may not have access to in-network storage of their own, but > they understand the protocol. > > At a high-level, we added two messages: > > 1) slr-bt-request: This is a request for a block from peer A to peer B that > includes an access token for A's in-network storage. Peer B may use the > token to directly store the block in A's storage. We use this message > instead of BitTorrent's 'request' message. > > 2) slr-bt-direct: This is used by peer B to indicate to peer A where to > retrieve the block. If peer B is using its own in-network storage, > then it includes an access token, and peer A downloads data from B's > in-network storage into its own storage, and then retrieves the block. > If B is not using its own in-network storage, then B stores the block > in to A's storage (using the token received from A), and A retrieves it > from there. > > There are a couple more specifics here that handle the cases when one or both > of the peers do not have access to in-network storage themselves (e.g., if > their ISP has not yet offered the service). If you are interested in the > details, I'd be happy to fill them in. I left them out for now since the > details may not be constructive at this point in the DECADE discussion :) > > -- > Richard Alimi > Department of Computer Science > Yale University > From abcdmatao@gmail.com Thu Sep 24 23:47:33 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 615A53A68AC for ; Thu, 24 Sep 2009 23:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.859 X-Spam-Level: X-Spam-Status: No, score=-1.859 tagged_above=-999 required=5 tests=[AWL=0.739, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6F1ROLEjbnl for ; Thu, 24 Sep 2009 23:47:32 -0700 (PDT) Received: from mail-iw0-f186.google.com (mail-iw0-f186.google.com [209.85.223.186]) by core3.amsl.com (Postfix) with ESMTP id 3D26C3A6892 for ; Thu, 24 Sep 2009 23:47:32 -0700 (PDT) Received: by iwn16 with SMTP id 16so318144iwn.29 for ; Thu, 24 Sep 2009 23:48:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=p0dekpkdqvraEVB8MFIO1QxwkrXRFGLJyplp92cRqdc=; b=DY1cP4LsU5mW4CvRX/VNTX17M1ARYqke5BiAJ8ST6dN6O2pmpptW2DxrWTQFZS6Jku COr6Nsoy0Ji1G+rhiVAbyIiT7q6i++/hc6dFkDLQdKwdC30eZYz4aGt4KLoq99nFr+fI mawNNMv5XVhyBL4v33In20LI+aTEiqX32tJx0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CLb2oinXSwatc20foKdMqcsshCE0v9yD4uVn1TZEwE+8iPh3Vraz42kAqWg8WADXYh B2q4bJiqcV8rXEk8BRptdONa3PTFObYVD8o0+My5sYMOkeH5V2OEHwN6Uo/KBF+MjnUs zJ0qOiM/bEPYLAbyKwER19JVxFfwbSw/2AAzY= MIME-Version: 1.0 Received: by 10.231.121.93 with SMTP id g29mr3604679ibr.13.1253861317307; Thu, 24 Sep 2009 23:48:37 -0700 (PDT) In-Reply-To: <200909240946.29246.richard.alimi@yale.edu> References: <99978d7d0909231842y14a0f6e7ke63ec22cf1976fa6@mail.gmail.com> <8b2769930909231930hb536754kee8616d8912ab4c7@mail.gmail.com> <200909240946.29246.richard.alimi@yale.edu> Date: Fri, 25 Sep 2009 14:48:37 +0800 Message-ID: <99978d7d0909242348i9a76363u65e3c1c11da28af5@mail.gmail.com> From: Tao Ma To: Richard Alimi , decade@ietf.org Content-Type: multipart/alternative; boundary=0016e646926a6a6de604746156b2 Cc: Chunhong Zhang , standardMINE@googlegroups.com Subject: Re: [decade] DECADE Charter discussion (Song Haibin) 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, 25 Sep 2009 06:47:33 -0000 --0016e646926a6a6de604746156b2 Content-Type: text/plain; charset=ISO-8859-1 Hi, I am interested in your Sailor work. Would you give me the website link or are there some papers about your Sailor project? Thanks. Tao Ma Mobile lIfe and New mEdia(MINE) Lab Beijing University of Posts and Telecommunications 2009/9/24 Richard Alimi > Hi David, > > > Do we have some P2P application developers here can comment? (I've > > implemented many P2P apps, but all for communications (VoIP, IM, etc), > > so we didn't really do object storage beyond rather small things like > > VM and configuration files...) > > While I wouldn't classify myself as a "P2P application developer", I can > comment a bit on how we accomplished our integration of BitTorrent with our > Sailor work. This is certainly not the only way it can be done, but I'm > mentioning it to give some intuition. We integrated with Vuze (formerly > Azureus) as a plugin, so some of our implementation reflects what could be > reasonably accomplished within Vuze's Plugin API (e.g., we avoided changing > formats for existing messages). > > After the initial handshake, peer A and B send each other a message > identifying the name/address and an identifier which uniquely identifies > the > in-network storage used by a peer. If a peer does not receive the > additional > handshake message from the other peer, it assumes the other peer does not > support the extension, and falls back to the traditional BitTorrent > protocol. > For the remainder, lets assume both peers support in-network storage. Note > that they may or may not have access to in-network storage of their own, > but > they understand the protocol. > > At a high-level, we added two messages: > > 1) slr-bt-request: This is a request for a block from peer A to peer B that > includes an access token for A's in-network storage. Peer B may use the > token to directly store the block in A's storage. We use this message > instead of BitTorrent's 'request' message. > > 2) slr-bt-direct: This is used by peer B to indicate to peer A where to > retrieve the block. If peer B is using its own in-network storage, > then it includes an access token, and peer A downloads data from B's > in-network storage into its own storage, and then retrieves the block. > If B is not using its own in-network storage, then B stores the block > in to A's storage (using the token received from A), and A retrieves it > from there. > > There are a couple more specifics here that handle the cases when one or > both > of the peers do not have access to in-network storage themselves (e.g., if > their ISP has not yet offered the service). If you are interested in the > details, I'd be happy to fill them in. I left them out for now since the > details may not be constructive at this point in the DECADE discussion :) > > -- > Richard Alimi > Department of Computer Science > Yale University > --0016e646926a6a6de604746156b2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,
I am interested in your Sailor work. Would you give me the website = link or are there some papers about your Sailor project? Thanks.
Tao Ma<= br>Mobile lIfe and New mEdia(MINE) Lab
Beijing University of Posts and T= elecommunications

2009/9/24 Richard Alimi &l= t;richard.alimi@yale.edu><= /span>
Hi David,

> Do we have some P2P application developers here can comment? (I've=
> implemented many P2P apps, but all for communications (VoIP, IM, etc),=
> so we didn't really do object storage beyond rather small things l= ike
> VM and configuration files...)

While I wouldn't classify myself as a "P2P application devel= oper", I can
comment a bit on how we accomplished our integration of BitTorrent with our=
Sailor work. =A0This is certainly not the only way it can be done, but I= 9;m
mentioning it to give some intuition. =A0We integrated with Vuze (formerly<= br> Azureus) as a plugin, so some of our implementation reflects what could be<= br> reasonably accomplished within Vuze's Plugin API (e.g., we avoided chan= ging
formats for existing messages).

After the initial handshake, peer A and B send each other a message
identifying the name/address and an identifier which uniquely identifies th= e
in-network storage used by a peer. =A0If a peer does not receive the additi= onal
handshake message from the other peer, it assumes the other peer does not support the extension, and falls back to the traditional BitTorrent protoco= l.
For the remainder, lets assume both peers support in-network storage. Note<= br> that they may or may not have access to in-network storage of their own, bu= t
they understand the protocol.

At a high-level, we added two messages:

1) slr-bt-request: This is a request for a block from peer A to peer B that=
=A0 includes an access token for A's in-network storage. =A0Peer B may= use the
=A0 token to directly store the block in A's storage. =A0We use this m= essage
=A0 instead of BitTorrent's 'request' message.

2) slr-bt-direct: This is used by peer B to indicate to peer A where to
=A0 retrieve the block. If peer B is using its own in-network storage,
=A0 then it includes an access token, and peer A downloads data from B'= ;s
=A0 in-network storage into its own storage, and then retrieves the block.=
=A0 If B is not using its own in-network storage, then B stores the block<= br> =A0 in to A's storage (using the token received from A), and A retriev= es it
=A0 from there.

There are a couple more specifics here that handle the cases when one or bo= th
of the peers do not have access to in-network storage themselves (e.g., if<= br> their ISP has not yet offered the service). =A0If you are interested in the=
details, I'd be happy to fill them in. =A0I left them out for now since= the
details may not be constructive at this point in the DECADE discussion :)
--
Richard Alimi
Department of Computer Science
Yale University

--0016e646926a6a6de604746156b2-- From lunohod.baikonur@googlemail.com Fri Sep 25 01:54:35 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 227D53A682F for ; Fri, 25 Sep 2009 01:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGOqEpW3yj1h for ; Fri, 25 Sep 2009 01:54:34 -0700 (PDT) Received: from mail-qy0-f195.google.com (mail-qy0-f195.google.com [209.85.221.195]) by core3.amsl.com (Postfix) with ESMTP id 246D63A67FC for ; Fri, 25 Sep 2009 01:54:34 -0700 (PDT) Received: by qyk33 with SMTP id 33so2089467qyk.29 for ; Fri, 25 Sep 2009 01:55:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.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; bh=pHfsSA4zlavTBCw+D8GlecjzqKn4+dJUgCf3UEK8L1c=; b=hrjl/DJ6bod63osgrR/sAb0quPsSGElvO7xHz84h0SvJrBUn/8sED7EHOGF3pOi95d LBBy9QvH2dcvKtnTUmwHPtJSnStJXoXTd0BCUPPn1Icug7FfxtUqWiIEWzIFnD3FzkPR wnUT3isifAimM6mH/RdOjoKz27nP9QeXfU+Ws= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=m1W6r0gyI6E4rz9/49CO7qHHV9HjZUY5u9OJYXVkjF1EyX90afhQJ7HFlsTsOkwPoQ KMzEkpDwuQBs9D/xnd54cD+1hgp2QBqzuYlj+LIq9gCksQATLkTAF07xd+e0/eiCFDFB MrrejL0TRx44myEOtW0Sd7q9rVXVCrS1/lzOU= MIME-Version: 1.0 Sender: lunohod.baikonur@googlemail.com Received: by 10.229.43.68 with SMTP id v4mr2104425qce.95.1253868940900; Fri, 25 Sep 2009 01:55:40 -0700 (PDT) In-Reply-To: <007101ca3c16$b942cbb0$1d0ca40a@china.huawei.com> References: <007101ca3c16$b942cbb0$1d0ca40a@china.huawei.com> Date: Fri, 25 Sep 2009 09:55:40 +0100 X-Google-Sender-Auth: d3adcb33c81789ad Message-ID: <29d3c4cb0909250155h5afe629fm10c6e7bfc22aaeb9@mail.gmail.com> From: Alexey Melnikov To: Song Haibin Content-Type: text/plain; charset=ISO-8859-1 Cc: decade@ietf.org Subject: Re: [decade] DECADE Charter discussion 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, 25 Sep 2009 08:54:35 -0000 This looks like a good start. I have a couple of comments on the current charter text: On Wed, Sep 23, 2009 at 7:26 AM, Song Haibin wrote: [...] > The Working Group (WG) will design and specify a standard protocol for P2P > applications to utilize in-network storage. This presupposes that you've reviewed existing protocols and found them to be unsuitable and not sufficiently extensible to address your needs. I think you wouldn't know for sure until after the survey document is done. > The protocol will include > operations for a P2P application system to (1) store and retrieve data, (2) > specify access control on who can store into and retrieve from its allocated > storage, and (3) indicate resource sharing policies. [...] > Goals and Milestones: > > Aug 2010 > Working Group Last Call for problem statement > Nov 2010 > Submit problem statement to IESG as Informational > Nov 2010 > Working Group Last Call for requirements document > Apr 2011 > Submit requirements document to IESG as Informational > Aug 2011 > Working Group Last Call for survey document > Dec 2011 > Working Group Last Call for in-network storage access protocol > Apr 2012 > Submit in-network storage access protocol to IESG as Proposed Standard > Apr 2011 > Submit survey document to IESG as informational > Aug 2012 > Dissolve or re-charter IESG typically complains about WG milestones being too aggressive. Your milestones look to be a bit too "relaxed". I am hoping that the problem statement document can be finished much quicker. From melodysong@huawei.com Fri Sep 25 02:35:02 2009 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 662703A6899 for ; Fri, 25 Sep 2009 02:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[AWL=0.405, 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 cU1kRQAaSTOH for ; Fri, 25 Sep 2009 02:35:01 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 888153A685B for ; Fri, 25 Sep 2009 02:35:01 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQI00HL7T8YYJ@szxga04-in.huawei.com> for decade@ietf.org; Fri, 25 Sep 2009 17:34:10 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQI00FLRT8XEF@szxga04-in.huawei.com> for decade@ietf.org; Fri, 25 Sep 2009 17:34:10 +0800 (CST) Received: from s64081 ([10.164.12.29]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQI0089RT8XNH@szxml06-in.huawei.com> for decade@ietf.org; Fri, 25 Sep 2009 17:34:09 +0800 (CST) Date: Fri, 25 Sep 2009 17:34:09 +0800 From: Song Haibin In-reply-to: <29d3c4cb0909250155h5afe629fm10c6e7bfc22aaeb9@mail.gmail.com> To: 'Alexey Melnikov' Message-id: <009001ca3dc3$556e4ed0$1d0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Aco9vlFEBzyh0v9KTOy3sDpb+T7CUAAAKRfw Cc: decade@ietf.org Subject: Re: [decade] DECADE Charter discussion 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, 25 Sep 2009 09:35:02 -0000 Hi Alexey, Thanks for your reply. >-----Original Message----- >From: lunohod.baikonur@googlemail.com >[mailto:lunohod.baikonur@googlemail.com] On Behalf Of Alexey Melnikov >Sent: Friday, September 25, 2009 4:56 PM >To: Song Haibin >Cc: decade@ietf.org >Subject: Re: [decade] DECADE Charter discussion > >This looks like a good start. >I have a couple of comments on the current charter text: > >On Wed, Sep 23, 2009 at 7:26 AM, Song Haibin > wrote: > [...] >> The Working Group (WG) will design and specify a standard >protocol for >> P2P applications to utilize in-network storage. > >This presupposes that you've reviewed existing protocols and >found them to be unsuitable and not sufficiently extensible to >address your needs. >I think you wouldn't know for sure until after the survey >document is done. > I agree. The survey document is very important and meaningful for this work. I guess the possible deficit of the existing protocols that makes them not suitable for this work is that they don't specify the resource sharing policies for p2p application, e.g. how the contents and processing resource in my in-network storage are shared with others. Whatever, we have to do the survey of related protocols in detail. >> The protocol will include >> operations for a P2P application system to (1) store and retrieve >> data, (2) specify access control on who can store into and retrieve >> from its allocated storage, and (3) indicate resource >sharing policies. > > [...] > >> Goals and Milestones: >> >> Aug 2010 >> Working Group Last Call for problem statement Nov 2010 >Submit problem >> statement to IESG as Informational Nov 2010 Working Group Last Call >> for requirements document Apr 2011 Submit requirements document to >> IESG as Informational Aug 2011 Working Group Last Call for survey >> document Dec 2011 Working Group Last Call for in-network storage >> access protocol Apr 2012 Submit in-network storage access >protocol to >> IESG as Proposed Standard Apr 2011 Submit survey document to IESG as >> informational Aug 2012 Dissolve or re-charter > >IESG typically complains about WG milestones being too aggressive. >Your milestones look to be a bit too "relaxed". I am hoping >that the problem statement document can be finished much quicker. > I think it is reasonable to change the milestones to make it a little "aggressive". Thanks, Haibin