From haibin.song@huawei.com Mon Jun 4 17:53:37 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA73621F878A for ; Mon, 4 Jun 2012 17:53:37 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXPyT36ISY3B for ; Mon, 4 Jun 2012 17:53:35 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id B9B4C21F8786 for ; Mon, 4 Jun 2012 17:53:35 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGV95628; Mon, 04 Jun 2012 20:53:35 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 4 Jun 2012 17:51:22 -0700 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 4 Jun 2012 17:51:22 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.45]) by szxeml415-hub.china.huawei.com ([10.82.67.154]) with mapi id 14.01.0323.003; Tue, 5 Jun 2012 08:51:12 +0800 From: Songhaibin To: "decade@ietf.org" Thread-Topic: Last Call: (Naming Things with Hashes) to Proposed Standard Thread-Index: AQHNQmU4ZDO/CiJP106K3ADqE4UWZ5bq5VeQ Date: Tue, 5 Jun 2012 00:51:12 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [decade] FW: Last Call: (Naming Things with Hashes) to Proposed Standard X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2012 00:53:38 -0000 Please review this document and see if we can use it in DECADE context. -Haibin > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Monday, June 04, 2012 11:17 PM > To: decade-chairs@tools.ietf.org > Subject: Fwd: Last Call: (Naming Things = with > Hashes) to Proposed Standard >=20 >=20 > FYI. If there's still decade interest in using this > it might be done soon! >=20 > Cheers, > S. >=20 > -------- Original Message -------- > Subject: Last Call: (Naming Things with > Hashes) to Proposed Standard > Date: Mon, 04 Jun 2012 07:18:04 -0700 > From: The IESG > Reply-To: ietf@ietf.org > To: IETF-Announce >=20 >=20 > The IESG has received a request from an individual submitter to consider > the following document: > - 'Naming Things with Hashes' > as Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-07-02. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > This document defines a set of ways to identify a thing using the > output from a hash function, specifying URI, URL, binary and human > "speakable" formats for these names. The various formats are > designed to support, but not require, a strong link to the referenced > object such that the referenced object may be authenticated to the > same degree as the reference to it. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-farrell-decade-ni/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-farrell-decade-ni/ballot/ >=20 >=20 > The following IPR Declarations may be related to this I-D: >=20 > http://datatracker.ietf.org/ipr/1773/ > http://datatracker.ietf.org/ipr/1775/ >=20 >=20 >=20 >=20 From haibin.song@huawei.com Mon Jun 4 18:56:13 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1236E11E80C9 for ; Mon, 4 Jun 2012 18:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1qxuqcnCV5w for ; Mon, 4 Jun 2012 18:56:12 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5C30511E80C2 for ; Mon, 4 Jun 2012 18:56:12 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGP00442; Mon, 04 Jun 2012 21:56:12 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 4 Jun 2012 18:52:49 -0700 Received: from SZXEML431-HUB.china.huawei.com (10.72.61.39) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 4 Jun 2012 18:52:49 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.45]) by szxeml431-hub.china.huawei.com ([10.72.61.39]) with mapi id 14.01.0323.003; Tue, 5 Jun 2012 09:52:46 +0800 From: Songhaibin To: "decade@ietf.org" Thread-Topic: IAB/IRTF workshop on Congestion Control for Interactive Real-Time Communication Thread-Index: Ac1CvectsVvheuerRG2PuxGd5iUevw== Date: Tue, 5 Jun 2012 01:52:46 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [decade] IAB/IRTF workshop on Congestion Control for Interactive Real-Time Communication X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2012 01:56:13 -0000 If you are interested, please get ready for it. ---------------------------------------------------------------------------= ---------- IAB / IRTF Workshop on Congestion Control for Interactive Real-Time Communication July 28, 2012 Vancouver, Canada =20 The IAB and IRTF will hold a workshop on Congestion Control for Interactive= Real-Time Communication" in Vancouver, Canada on Saturday, July 28th, 2012= prior to the IETF-84 meeting (see http://www.ietf.org/meeting/84/index.htm= l). Participation at the workshop is free of charge. There is no requireme= nt to either register with or attend the IETF-84 meeting that follows the w= orkshop. =20 The workshop organizers would like to foster a discussion on: 1. What are appropriate congestion signals to use for interactive media and= data? 2. What existing congestion control algorithms are appropriate for interact= ive media and data? What properties would be desirable in new congestion co= ntrol algorithms? 3. Measurement and/or simulations of new congestion signals (e.g., delay-ba= sed) and their interaction with existing congestion control mechanisms. 4. What are good available techniques for adjusting sending rates for inter= active media and data? What are the limits of those techniques? What proper= ties would be desirable in new techniques? 5. What application-specific considerations have to be taken into account? 6. How can we ensure that real-time communications are well-behaved with re= spect to other Internet applications while still providing good quality? 7. What should the IETF and/or IRTF do? The organizers seek position papers on any or all of these topics, as well = as other topics related to congestion control for interactive realtime medi= a. =20 Every prospective workshop participant must submit a position paper contain= ing a name and an email address. Authors of accepted papers will be invited= to the workshop. Papers up to 3 pages, formatted in HTML, PDF, or plain te= xt (for example, as a submitted Internet-Draft) are ideal. Accepted positio= n papers will be published. Additional details about the meeting venue wil= l be provided to authors of accepted papers. Important Dates Position paper submission deadline: June 23, 2012 Notification to paper authors: June 30, 2012 Workshop date: July 28, 2012 Additional Details Additional details on the workshop as well as the submission process is ava= ilable at http://www.iab.org/cc-workshop/ Contact To sponsors: If you are interested to help us working towards better intera= ctive media congestion control mechanisms on the Internet (such as by makin= g a contribution towards catering costs and room rental), please contact us= ! In case of questions please send email to mary.ietf.barnes at gmail.com. From Dirk.Kutscher@neclab.eu Tue Jun 5 02:16:47 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C4F21F86B9 for ; Tue, 5 Jun 2012 02:16:47 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwKDKV-XcoMT for ; Tue, 5 Jun 2012 02:16:42 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDF921F853D for ; Tue, 5 Jun 2012 02:16:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 3A3E51013E6 for ; Tue, 5 Jun 2012 11:17:40 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMCi1-FrCtQA for ; Tue, 5 Jun 2012 11:17:40 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 1E23C1013E5 for ; Tue, 5 Jun 2012 11:17:35 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.172]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 5 Jun 2012 11:16:15 +0200 From: Dirk Kutscher To: "decade@ietf.org" Thread-Topic: NetInf software update: nilib-20120603-v01a Thread-Index: Ac1C+F/zlHnruCtiSg+8NSJb1wkIcwAA0/9Q Date: Tue, 5 Jun 2012 09:16:14 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F524924CDC63D@Polydeuces.office.hd> References: <82AB329A76E2484D934BBCA77E9F524924CDC572@Polydeuces.office.hd> In-Reply-To: <82AB329A76E2484D934BBCA77E9F524924CDC572@Polydeuces.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.204] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [decade] FW: NetInf software update: nilib-20120603-v01a X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2012 09:16:47 -0000 FYI -- this implements the latest version of draft-farrell-decade-ni that H= aibin sent around yesterday. Best regards, Dirk -----Original Message----- From: icnrg-bounces@irtf.org [mailto:icnrg-bounces@irtf.org] On Behalf Of D= irk Kutscher Sent: Dienstag, 5. Juni 2012 10:53 To: icnrg@irtf.org Subject: [icnrg] NetInf software update: nilib-20120603-v01a Hello, We (a group of individuals working on ICN in the SAIL project [1]) have rel= eased an update of the open source NetInf software package at https://sourc= eforge.net/projects/netinf/ . This implements the latest versions of draft-farrell-decade-ni [2] and draf= t-hallambaker-decade-ni-params [3], which have several new features, includ= ing: - truncated hash suites - binary name format - human-readable format The package provides implementations of the naming specification and other = features (such as NetInf convergence layers, forwarding, caching) in differ= ent languages, including C, Clojure, Java, PHP, Python, and Ruby. There are= also additional tools such as patches to curl and wget and shells scripts = for web server support. We have been using these components in interop tests but please note that t= his is work in progress. The latest version is nilib-20120603-v01a.tar.gz. The software is licensed = under Apache-2.0 [4]. Best regards, Dirk [1] http://www.sail-project.eu/ [2] http://datatracker.ietf.org/doc/draft-farrell-decade-ni/ [3] http://datatracker.ietf.org/doc/draft-hallambaker-decade-ni-params/ [4] http://www.apache.org/licenses/LICENSE-2.0 -- Dr. Dirk Kutscher | NEC Laboratories Europe phone: +49 6221 4342 203 | fax: +49 6221 4342 155 | webpage: www.neclab.eu NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014 _______________________________________________ icnrg mailing list icnrg@irtf.org https://www.irtf.org/mailman/listinfo/icnrg From wangdanhua@huawei.com Wed Jun 13 00:47:34 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9441B21F8568 for ; Wed, 13 Jun 2012 00:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okPNFdHo69rM for ; Wed, 13 Jun 2012 00:47:34 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id EE07A21F855F for ; Wed, 13 Jun 2012 00:47:33 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGW36938; Wed, 13 Jun 2012 03:47:33 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 13 Jun 2012 00:47:25 -0700 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 13 Jun 2012 00:47:24 -0700 Received: from SZXEML507-MBX.china.huawei.com ([169.254.8.160]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 13 Jun 2012 15:47:19 +0800 From: Wangdanhua To: "decade@ietf.org" Thread-Topic: =?Windows-1252?Q?A_few_open_issues_about_=93An_HTTP-based_DECADE_Resource?= =?Windows-1252?Q?_Protocol=94.?= Thread-Index: Ac1JOMEUrstJoJm3TV6IKmRtUzWawg== Date: Wed, 13 Jun 2012 07:47:18 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.177] Content-Type: multipart/alternative; boundary="_000_AFD688AF30E249418739DBDC55B9C75B34D4603ESZXEML507MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [decade] =?windows-1252?q?A_few_open_issues_about_=93An_HTTP-base?= =?windows-1252?q?d_DECADE_Resource_Protocol=94=2E?= X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2012 07:47:34 -0000 --_000_AFD688AF30E249418739DBDC55B9C75B34D4603ESZXEML507MBXchi_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, Here are some open issues about =93An HTTP-based DECADE Resource Protocol= =94 we would like to discuss in the mailing list. Any opinions or suggestio= ns are welcomed and appreciated. 1. As to the SDT part, do we need to include push (subscription) mode= l beyond pull mode? 2. As to the DRP part, can we implement AAA (resource) or OAuth to ge= nerate token? 3. The detailed design of the token structure/HTTP authentication for= mat. Looking forward to your feedback. Best wishes, Danhua Wang --_000_AFD688AF30E249418739DBDC55B9C75B34D4603ESZXEML507MBXchi_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Here are some open issues ab= out =93An HTTP-based DECADE Resource Protocol=94 we would like to discuss in the mailing list. Any opinions or suggestions are welcomed and appreciated.

 

1= .   &= nbsp;   As to the SDT part, do = we need to include push (subscription) model beyond pull mode?

2= .   &= nbsp;   As to the DRP part, can= we implement AAA (resource) or OAuth to generate token?<= /p>

3= .   &= nbsp;   The detailed design of = the token structure/HTTP authentication format.

 

Looking forward to your feed= back.

 

Best wishes,

Danhua Wang

 

--_000_AFD688AF30E249418739DBDC55B9C75B34D4603ESZXEML507MBXchi_-- From zongning@huawei.com Wed Jun 13 00:56:11 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6DE021F86E8 for ; Wed, 13 Jun 2012 00:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.599 X-Spam-Level: X-Spam-Status: No, score=-101.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnuEoL7d8DJF for ; Wed, 13 Jun 2012 00:56:08 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 995AD21F85C4 for ; Wed, 13 Jun 2012 00:56:08 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHD37910; Wed, 13 Jun 2012 03:56:08 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 13 Jun 2012 00:54:15 -0700 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 13 Jun 2012 00:54:18 -0700 Received: from SZXEML504-MBX.china.huawei.com ([169.254.4.129]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.003; Wed, 13 Jun 2012 15:54:13 +0800 From: Zongning To: Richard Alimi , "decade@ietf.org" Thread-Topic: [decade] WG Review of draft-ietf-decade-integration-example-03 Thread-Index: AQHNMGqbJm7tcUHzJ06dfR5ih4JZn5b39CSQ Date: Wed, 13 Jun 2012 07:54:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [decade] WG Review of draft-ietf-decade-integration-example-03 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2012 07:56:11 -0000 Hi, Rich, Sorry for the late reply. Please see below my response. I think most of your comments are valuable and I will incorporate these in = the new revision soon. -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of= Richard Alimi Sent: Sunday, May 13, 2012 2:10 AM To: decade@ietf.org Subject: [decade] WG Review of draft-ietf-decade-integration-example-03 The following is my review of draft-ietf-decade-integration-example-03. Overall, the document is much improved. It could still use some general revision for grammar and to make the wording more concise. >>[Ning]: Thanks. Detailed review: ** Introduction s/firstly/first "we only show the feasibility of ALTO and INS without comparing to other content distribution systems at this time" - what other "content distribution systems" would be compared against? >>[Ning]: IMO, it could be CDN, but we don't have real plan for comparison = . - if not at this time, is that planned for a future iteration of this draft (if not I'd suggest removing "at this time") >>[Ning]: No, we don't have such plan. I will rephrase this sentence. ** Terminlogy add definition for "native application client" >>[Ning]: Agree. INS Service Provider - does it deploy the entire INS system, or just some servers? >>[Ning]: It mostly needs to deploy INS servers, portal for application acc= ess, and probably dispatch INS plug-in for application. INS Portal - why simulated? what's a simulated portal? >>[Ning]: I will change the wording. How about just "point for application = access"? - don't use 'portal' in order to define the term >>[Ning]: Agree. ** INS Client API define what a 'token' is (or provide a reference) >>[Ning]: Agree. s/authorized token/authorization token/ why does the particular example (ALTO + INS) determine who generates the token? Is this detail necessary in the API description? >>[Ning]: I will remove this from API description. ** Integration of P2P Live Streaming and INS System Introductory sentence can be simplified to just "We integrate an INS client into a P2P live streaming client." The rest is repetative. >>[Ning]: Agree. what does it mean to be "compatible with original P2P live streaming signalling"? Is it more accurate to just say that existing signallling is still used? >>[Ning]: I would delete this sentence as all the detail is in control mess= age section. "whose size can be application-customized according to the variable requirements of of performance or sensitive factors" - wording seems awkward. How about something like "the API supports variable-sized blocks to cater to different application requirements (e.g., latency and throughput)." >>[Ning]: Agree. For live streaming, in what sense are they "bittorrent-like"? Piece exchanges? (the concept of the torrent file and piece map doesn't directly apply without modifications) >>[Ning]: I think BitTorrent-like is misleading and I would reword this. We= were using a Lab-based P2P live streaming system only for research purpose= . "On the other hand, INS-enabled .." - remove "on the other hand" >>[Ning]: Agree. is the token exchange message the reason for the INS Client <-> INS Client line in Figure 1? If so, explain in the "Control Messages" section tha tthis does not use (or extend) the native application protocol. >>[Ning]: Yes, and I will explain this in control message section. To what extent are the recommendations based on the fact that M=3D1 in the implementation? The stronger argument to make might be that the INS server may need to concurrently serve many thousands (or more) clients. >>[Ning]: Each server has M=3D1 connect to EACH client, NOT all clients. "can use this range token to access all available data objects in the INS server" - make it clear that it isn't all objects in the server, but only those to which it was permitted access >>[Ning]: Agree. The design considerations would be a lot more convincing and easier to follow if the message flow were discussed before making the recommendations. Otherwise, the reader is less clear on the particular problem being solved. (Presenting filesharing before live streaming may solve the problem.) >>[Ning]: Good point, I will see how to improve this. Changing section orde= r could be one approach. ** Integration of P2P file sharing and INS system Is Figure 1 basically the same as Figure 2 with the exception of Figure 2 saying Vuze? If they are the same, perhaps just present the general architecture at the beginning of the document and say it works with both filesharing and live streaming (reuse is a good thing). >>[Ning]: Yes, and it is good point to have one common picture. Either explain why it is an "Azureous handshake" or replace it with just "handshake reply" or similar >>[Ning]: "handshake reply" is fine here. There seems to be a transition sentence missing before the details of Figure 4 are discussed. >>[Ning]: I will add some sentence here. Are ther eany additional lessons/recommendatons based on the filesharing integration? Even if there aren't, it seems like there should be some sort of concluding remarks in that section. >>[Ning]: I will add some short conclusion remark. ** Integration of ALTO and INS System for File Distribution Alto doesn't (typically) give information to end users. It gives information to applications run by those end users :) >>[Ning]: OK, I will change the wording. s/content servers/content providers/ alto won't help reduce bandwidth consumption for the end host (the current text seems to imply that). make it clear that it can reduce network usage within ISP >>[Ning]: OK, I will change the wording. s/Architecture Design/Architecture/ how does alto help CPs to upload files ot INS servers? >>[Ning]: No. ALTO doesn't do this. I will modify. In Figure 5, why don't End Users talk to INS Servers? It makes it look like the CP Portal and INS Portal are on the data path for downloads. Similar comment for End Users and ALTO Server. >>[Ning]: Figure 5 is not data patch, but logical connection between the co= mponents. Some redirections can also happen between them. I will try to mak= e this more clear. In Figure 6, why not have the Portal redirect the uploder to an INS server instead of acting as a proxy? Acting as a proxy means the portal (a server or set of servers presumably) must have an aggregate network capacity equal to the sum of the total upload rate that it wishes to provide to all the INS servers. By not using the proxy design, it also means the INS Portal no longer needs to define protocol messaging for communicating things like placement policies. >>[Ning]: In many cases that one CP distribute many copies of many INS serv= ers, a proxy in INS provider could reduce the load of CP. Also note that IN= S provider may not want to disclose its INS servers to CP. s/HTTP_POST/HTTP POST/ In the downloading procedure, is the user using a standard web browser? From the description, it seems like there must be some sort of INS extension installed in the web browser (in order to understand tokens, know how to communicate with INS servers, etc). That should be stated. >>[Ning]: User uses web-browser with INS plug-in. What is the relationship between the ISP and the INS Service Provider? Does the INS Service Provider have servers in multiple ISPs (in which case it would make sense to consult ALTO servers from each ISP). Or is the INS Service Provider the same as the ISP? >>[Ning]: We tried to decouple the ISP and INS provider when doing experime= nt. As you see we actually used PlanetLab and EC2 for deploying INS server.= The options you mentioned are all possible and open question when deployin= g INS system. How is "optimal" decided? >>[Ning]: How about change to "INS server suggested by ALTO"? ** Test Environment and Settings Avoid using the word "cloud". They are large sets of servers available for = use. >>[Ning]: Agree. wild-spread area -> global? >>[Ning]: Not global yet. We deployed servers mainly on US and Europe. how is geolocation distance computed? >>[Ning]: We just decide which clients connect to which server based on cli= ent IP address. So, it is basically region-based and very coarse. Figure 9 - also include where the servers were in the figure? (like Figure= 8) >>[Ning]: Agree. s/leeches/leechers/ would it be simpler to just assume PlanetLab Manager was part of the text controller and not mention it explicitly? >>[Ning]: PlanetLab Manager is not part of test controller. See different s= ections for their definitions. "4G CPU" -> 4 CPU? (or, did you find 4-Ghz CPUs?) If you found a VM with 4 billion CPUs that were halfway-decent, we should chat :) >>[Ning]: Good question:). It is actually assigned with 4 core from 16 core= 1Ghz CPU. For filesharing, why is there 480MB of download traffic in the INS case but 430MB in the native case? >>[Ning]: Because PlanetLab clients are not controlled by us, not all clien= ts will finish downloading process. So for independent tests, there are dif= ferent total download traffic. Can an INS server always supply 94%, or only when there was a 1Gbps NIC? More specifically, does it supply 9.4Gbps with a 10Gbps NIC? >>[Ning]: We did test on 100Mbps and 1Gbps NIC, and got same result of 94%. it would be interesting to note what scaling issues you found passed 400 concurrent users at an INS server. >>[Ning]: When we tried 450 concur users, 50 users didn't start downloading= at the same time with other 400 users. -Ning From haibin.song@huawei.com Wed Jun 13 02:32:10 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFA121F8543 for ; Wed, 13 Jun 2012 02:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyibGf2KQUHl for ; Wed, 13 Jun 2012 02:32:09 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4413621F8568 for ; Wed, 13 Jun 2012 02:32:05 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHD42828; Wed, 13 Jun 2012 05:32:05 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 13 Jun 2012 02:29:43 -0700 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 13 Jun 2012 02:29:41 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.45]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.003; Wed, 13 Jun 2012 17:29:38 +0800 From: Songhaibin To: Richard Alimi , "decade@ietf.org" Thread-Topic: [decade] WG Review of draft-ietf-decade-integration-example-03 Thread-Index: AQHNMGqZnFD1/6BJQ0yJfRNoKdEfo5b3wb2A Date: Wed, 13 Jun 2012 09:29:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [decade] WG Review of draft-ietf-decade-integration-example-03 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2012 09:32:10 -0000 Thanks to Rich Alimi for a very good review. Besides that, here are some de= tailed comments from myself. In the abstract section, please do NOT refer to the working group. This is = also applied to the first paragraph of Introduction. In section 3, last paragraph, it mentioned "In our P2P live streaming examp= le, the token is generated by INS client", I think it should be clear that = the token is generated by the INS client that is sharing its data. Section 4.2.1, for the batch request, we may change the wording "an applica= tion client may combine multiple requests in a single request" to "an appli= cation client may request a batch of data objects in a single request". Change "Larger Data Object" to "Large Data Object", otherwise, what is it c= ompared to? Section 5.2, can you give the reference to Vuze messages to a more specific= webpage instead of "www.vuze.com"? Figure 5, it is better to make it upside down, with "end user" in the botto= m, so as to be consistent with other figures. Section 7.4, delete more spaces before "ALTO", "End" and "CP". 2G/2GB 10= G/10GB Section 8.2.2, could the authors clarify the reason behind the high network= resource efficiency when compared to native P2P applications? BR, -Haibin > -----Original Message----- > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf = Of > Richard Alimi > Sent: Sunday, May 13, 2012 2:10 AM > To: decade@ietf.org > Subject: [decade] WG Review of draft-ietf-decade-integration-example-03 >=20 > The following is my review of > draft-ietf-decade-integration-example-03. Overall, the document is > much improved. It could still use some general revision for grammar > and to make the wording more concise. >=20 > Detailed review: >=20 > ** Introduction >=20 > s/firstly/first >=20 > "we only show the feasibility of ALTO and INS without comparing to > other content distribution systems at this time" > - what other "content distribution systems" would be compared against? > - if not at this time, is that planned for a future iteration of > this draft (if not I'd suggest removing "at this time") >=20 > ** Terminlogy >=20 > add definition for "native application client" >=20 > INS Service Provider > - does it deploy the entire INS system, or just some servers? >=20 > INS Portal > - why simulated? what's a simulated portal? > - don't use 'portal' in order to define the term >=20 > ** INS Client API >=20 > define what a 'token' is (or provide a reference) >=20 > s/authorized token/authorization token/ >=20 > why does the particular example (ALTO + INS) determine who generates > the token? Is this detail necessary in the API description? >=20 > ** Integration of P2P Live Streaming and INS System >=20 > Introductory sentence can be simplified to just "We integrate an INS > client into a P2P live streaming client." The rest is repetative. >=20 > what does it mean to be "compatible with original P2P live streaming > signalling"? Is it more accurate to just say that existing > signallling is still used? >=20 > "whose size can be application-customized according to the variable > requirements of of performance or sensitive factors" - wording seems > awkward. How about something like "the API supports variable-sized > blocks to cater to different application requirements (e.g., latency > and throughput)." >=20 > For live streaming, in what sense are they "bittorrent-like"? Piece > exchanges? (the concept of the torrent file and piece map doesn't > directly apply without modifications) >=20 > "On the other hand, INS-enabled .." - remove "on the other hand" >=20 > is the token exchange message the reason for the INS Client <-> INS > Client line in Figure 1? If so, explain in the "Control Messages" > section tha tthis does not use (or extend) the native application > protocol. >=20 > To what extent are the recommendations based on the fact that M=3D1 in > the implementation? The stronger argument to make might be that the > INS server may need to concurrently serve many thousands (or more) > clients. >=20 > "can use this range token to access all available data objects in the > INS server" - make it clear that it isn't all objects in the server, > but only those to which it was permitted access >=20 > The design considerations would be a lot more convincing and easier to > follow if the message flow were discussed before making the > recommendations. Otherwise, the reader is less clear on the > particular problem being solved. (Presenting filesharing before live > streaming may solve the problem.) >=20 > ** Integration of P2P file sharing and INS system >=20 > Is Figure 1 basically the same as Figure 2 with the exception of > Figure 2 saying Vuze? If they are the same, perhaps just present the > general architecture at the beginning of the document and say it works > with both filesharing and live streaming (reuse is a good thing). >=20 > Either explain why it is an "Azureous handshake" or replace it with > just "handshake reply" or similar >=20 > There seems to be a transition sentence missing before the details of > Figure 4 are discussed. >=20 > Are ther eany additional lessons/recommendatons based on the > filesharing integration? Even if there aren't, it seems like there > should be some sort of concluding remarks in that section. >=20 > ** Integration of ALTO and INS System for File Distribution >=20 > Alto doesn't (typically) give information to end users. It gives > information to applications run by those end users :) >=20 > s/content servers/content providers/ >=20 > alto won't help reduce bandwidth consumption for the end host (the > current text seems to imply that). make it clear that it can reduce > network usage within ISP >=20 > s/Architecture Design/Architecture/ >=20 > how does alto help CPs to upload files ot INS servers? >=20 > In Figure 5, why don't End Users talk to INS Servers? It makes it > look like the CP Portal and INS Portal are on the data path for > downloads. Similar comment for End Users and ALTO Server. >=20 > In Figure 6, why not have the Portal redirect the uploder to an INS > server instead of acting as a proxy? Acting as a proxy means the > portal (a server or set of servers presumably) must have an aggregate > network capacity equal to the sum of the total upload rate that it > wishes to provide to all the INS servers. By not using the proxy > design, it also means the INS Portal no longer needs to define > protocol messaging for communicating things like placement policies. >=20 > s/HTTP_POST/HTTP POST/ >=20 > In the downloading procedure, is the user using a standard web > browser? From the description, it seems like there must be some sort > of INS extension installed in the web browser (in order to understand > tokens, know how to communicate with INS servers, etc). That should > be stated. >=20 > What is the relationship between the ISP and the INS Service Provider? > Does the INS Service Provider have servers in multiple ISPs (in which > case it would make sense to consult ALTO servers from each ISP). Or > is the INS Service Provider the same as the ISP? >=20 > How is "optimal" decided? >=20 > ** Test Environment and Settings >=20 > Avoid using the word "cloud". They are large sets of servers available fo= r use. >=20 > wild-spread area -> global? >=20 > how is geolocation distance computed? >=20 > Figure 9 - also include where the servers were in the figure? (like Figu= re 8) >=20 > s/leeches/leechers/ >=20 > would it be simpler to just assume PlanetLab Manager was part of the > text controller and not mention it explicitly? >=20 > "4G CPU" -> 4 CPU? (or, did you find 4-Ghz CPUs?) If you found a VM > with 4 billion CPUs that were halfway-decent, we should chat :) >=20 > For filesharing, why is there 480MB of download traffic in the INS > case but 430MB in the native case? >=20 > Can an INS server always supply 94%, or only when there was a 1Gbps > NIC? More specifically, does it supply 9.4Gbps with a 10Gbps NIC? >=20 > it would be interesting to note what scaling issues you found passed > 400 concurrent users at an INS server. From haibin.song@huawei.com Wed Jun 13 02:46:05 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3FD21F867B for ; Wed, 13 Jun 2012 02:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.349 X-Spam-Level: X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LB38x4z5tjsT for ; Wed, 13 Jun 2012 02:46:04 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id BFCEF21F8668 for ; Wed, 13 Jun 2012 02:46:04 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHD43612; Wed, 13 Jun 2012 05:46:04 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 13 Jun 2012 02:44:10 -0700 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 13 Jun 2012 02:44:14 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.45]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.003; Wed, 13 Jun 2012 17:44:06 +0800 From: Songhaibin To: "decade@ietf.org" Thread-Topic: WG status update Thread-Index: Ac1JSRGsemc1KIqGTDeMn0fS68Li5Q== Date: Wed, 13 Jun 2012 09:44:05 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [decade] WG status update X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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, 13 Jun 2012 09:46:05 -0000 Hi folks, Here is a summary of the WG status. New revisions to DECADE requirements/architecture documents are expected to= solve Dave Crocker's comments. Rich and I joined the discussion with the a= uthors for the next step. We would like to see the new document ASAP. Since= there are many changes to the architecture document. The chairs would like= to have another WGLC after that. New revision to the DECADE integration example document is expected to solv= e the WG reviews. After that, there will be a last call. The DECADE problem statement draft is in RFC editor's queue, and will not t= ake long time before publication. thanks, -Haibin and Rich (as co-chairs) From zongning@huawei.com Wed Jun 13 19:12:38 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D9011E80D2 for ; Wed, 13 Jun 2012 19:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.599 X-Spam-Level: X-Spam-Status: No, score=-101.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8AFVoGVHFxS for ; Wed, 13 Jun 2012 19:12:37 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2B81A11E8072 for ; Wed, 13 Jun 2012 19:12:37 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHD97368; Wed, 13 Jun 2012 22:12:36 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 13 Jun 2012 19:12:13 -0700 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 13 Jun 2012 19:12:18 -0700 Received: from SZXEML504-MBX.china.huawei.com ([169.254.4.129]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Thu, 14 Jun 2012 10:12:08 +0800 From: Zongning To: Songhaibin Thread-Topic: [decade] WG Review of draft-ietf-decade-integration-example-03 Thread-Index: AQHNMGqZnFD1/6BJQ0yJfRNoKdEfo5b3wb2AgAF4R9CAAADtoA== Date: Thu, 14 Jun 2012 02:12:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "decade@ietf.org" Subject: Re: [decade] WG Review of draft-ietf-decade-integration-example-03 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jun 2012 02:12:38 -0000 Hi, Haibin, Thanks for your comments. Please see reply below. > > -----Original Message----- > > From: Songhaibin > > Sent: Wednesday, June 13, 2012 5:30 PM > > To: 'Richard Alimi'; decade@ietf.org > > Subject: RE: [decade] WG Review of draft-ietf-decade-integration-exampl= e-03 > > > > Thanks to Rich Alimi for a very good review. Besides that, here are som= e > detailed > > comments from myself. > > > > In the abstract section, please do NOT refer to the working group. This= is also > > applied to the first paragraph of Introduction. [Ning]: Agree. > > > > In section 3, last paragraph, it mentioned "In our P2P live streaming e= xample, > the > > token is generated by INS client", I think it should be clear that the = token is > > generated by the INS client that is sharing its data. [Ning]: Agree. > > > > Section 4.2.1, for the batch request, we may change the wording "an > application > > client may combine multiple requests in a single request" to "an applic= ation > client > > may request a batch of data objects in a single request". [Ning]: Agree. > > > > Change "Larger Data Object" to "Large Data Object", otherwise, what is = it > > compared to? [Ning]: Larger is compared to the typical existing P2P live streaming appli= cation. > > > > Section 5.2, can you give the reference to Vuze messages to a more spec= ific > > webpage instead of "www.vuze.com"? [Ning]: OK, I will give better reference. > > > > Figure 5, it is better to make it upside down, with "end user" in the b= ottom, > so as > > to be consistent with other figures. [Ning]: Agree. > > > > Section 7.4, delete more spaces before "ALTO", "End" and "CP". 2G/2GB > > 10G/10GB [Ning]: OK. > > > > Section 8.2.2, could the authors clarify the reason behind the high net= work > > resource efficiency when compared to native P2P applications? [Ning]: OK, I will clarify this. One reason is that INS server can always s= erver content to peers while in traditional P2P applications, peer have to = finish downloading content before sharing with others. > > > > BR, > > -Haibin > > > > > -----Original Message----- > > > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On > Behalf > > Of > > > Richard Alimi > > > Sent: Sunday, May 13, 2012 2:10 AM > > > To: decade@ietf.org > > > Subject: [decade] WG Review of draft-ietf-decade-integration-example-= 03 > > > > > > The following is my review of > > > draft-ietf-decade-integration-example-03. Overall, the document is > > > much improved. It could still use some general revision for grammar > > > and to make the wording more concise. > > > > > > Detailed review: > > > > > > ** Introduction > > > > > > s/firstly/first > > > > > > "we only show the feasibility of ALTO and INS without comparing to > > > other content distribution systems at this time" > > > - what other "content distribution systems" would be compared > against? > > > - if not at this time, is that planned for a future iteration of > > > this draft (if not I'd suggest removing "at this time") > > > > > > ** Terminlogy > > > > > > add definition for "native application client" > > > > > > INS Service Provider > > > - does it deploy the entire INS system, or just some servers? > > > > > > INS Portal > > > - why simulated? what's a simulated portal? > > > - don't use 'portal' in order to define the term > > > > > > ** INS Client API > > > > > > define what a 'token' is (or provide a reference) > > > > > > s/authorized token/authorization token/ > > > > > > why does the particular example (ALTO + INS) determine who generates > > > the token? Is this detail necessary in the API description? > > > > > > ** Integration of P2P Live Streaming and INS System > > > > > > Introductory sentence can be simplified to just "We integrate an INS > > > client into a P2P live streaming client." The rest is repetative. > > > > > > what does it mean to be "compatible with original P2P live streaming > > > signalling"? Is it more accurate to just say that existing > > > signallling is still used? > > > > > > "whose size can be application-customized according to the variable > > > requirements of of performance or sensitive factors" - wording seems > > > awkward. How about something like "the API supports variable-sized > > > blocks to cater to different application requirements (e.g., latency > > > and throughput)." > > > > > > For live streaming, in what sense are they "bittorrent-like"? Piece > > > exchanges? (the concept of the torrent file and piece map doesn't > > > directly apply without modifications) > > > > > > "On the other hand, INS-enabled .." - remove "on the other hand" > > > > > > is the token exchange message the reason for the INS Client <-> INS > > > Client line in Figure 1? If so, explain in the "Control Messages" > > > section tha tthis does not use (or extend) the native application > > > protocol. > > > > > > To what extent are the recommendations based on the fact that M=3D1 i= n > > > the implementation? The stronger argument to make might be that the > > > INS server may need to concurrently serve many thousands (or more) > > > clients. > > > > > > "can use this range token to access all available data objects in the > > > INS server" - make it clear that it isn't all objects in the server, > > > but only those to which it was permitted access > > > > > > The design considerations would be a lot more convincing and easier t= o > > > follow if the message flow were discussed before making the > > > recommendations. Otherwise, the reader is less clear on the > > > particular problem being solved. (Presenting filesharing before live > > > streaming may solve the problem.) > > > > > > ** Integration of P2P file sharing and INS system > > > > > > Is Figure 1 basically the same as Figure 2 with the exception of > > > Figure 2 saying Vuze? If they are the same, perhaps just present the > > > general architecture at the beginning of the document and say it work= s > > > with both filesharing and live streaming (reuse is a good thing). > > > > > > Either explain why it is an "Azureous handshake" or replace it with > > > just "handshake reply" or similar > > > > > > There seems to be a transition sentence missing before the details of > > > Figure 4 are discussed. > > > > > > Are ther eany additional lessons/recommendatons based on the > > > filesharing integration? Even if there aren't, it seems like there > > > should be some sort of concluding remarks in that section. > > > > > > ** Integration of ALTO and INS System for File Distribution > > > > > > Alto doesn't (typically) give information to end users. It gives > > > information to applications run by those end users :) > > > > > > s/content servers/content providers/ > > > > > > alto won't help reduce bandwidth consumption for the end host (the > > > current text seems to imply that). make it clear that it can reduce > > > network usage within ISP > > > > > > s/Architecture Design/Architecture/ > > > > > > how does alto help CPs to upload files ot INS servers? > > > > > > In Figure 5, why don't End Users talk to INS Servers? It makes it > > > look like the CP Portal and INS Portal are on the data path for > > > downloads. Similar comment for End Users and ALTO Server. > > > > > > In Figure 6, why not have the Portal redirect the uploder to an INS > > > server instead of acting as a proxy? Acting as a proxy means the > > > portal (a server or set of servers presumably) must have an aggregate > > > network capacity equal to the sum of the total upload rate that it > > > wishes to provide to all the INS servers. By not using the proxy > > > design, it also means the INS Portal no longer needs to define > > > protocol messaging for communicating things like placement policies. > > > > > > s/HTTP_POST/HTTP POST/ > > > > > > In the downloading procedure, is the user using a standard web > > > browser? From the description, it seems like there must be some sort > > > of INS extension installed in the web browser (in order to understand > > > tokens, know how to communicate with INS servers, etc). That should > > > be stated. > > > > > > What is the relationship between the ISP and the INS Service Provider= ? > > > Does the INS Service Provider have servers in multiple ISPs (in whic= h > > > case it would make sense to consult ALTO servers from each ISP). Or > > > is the INS Service Provider the same as the ISP? > > > > > > How is "optimal" decided? > > > > > > ** Test Environment and Settings > > > > > > Avoid using the word "cloud". They are large sets of servers availabl= e for > use. > > > > > > wild-spread area -> global? > > > > > > how is geolocation distance computed? > > > > > > Figure 9 - also include where the servers were in the figure? (like = Figure 8) > > > > > > s/leeches/leechers/ > > > > > > would it be simpler to just assume PlanetLab Manager was part of the > > > text controller and not mention it explicitly? > > > > > > "4G CPU" -> 4 CPU? (or, did you find 4-Ghz CPUs?) If you found a VM > > > with 4 billion CPUs that were halfway-decent, we should chat :) > > > > > > For filesharing, why is there 480MB of download traffic in the INS > > > case but 430MB in the native case? > > > > > > Can an INS server always supply 94%, or only when there was a 1Gbps > > > NIC? More specifically, does it supply 9.4Gbps with a 10Gbps NIC? > > > > > > it would be interesting to note what scaling issues you found passed > > > 400 concurrent users at an INS server. From haibin.song@huawei.com Wed Jun 13 23:00:34 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2040C21F864C for ; Wed, 13 Jun 2012 23:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=-1.667, BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xK8Bc4gNbKcJ for ; Wed, 13 Jun 2012 23:00:32 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8D39921F864A for ; Wed, 13 Jun 2012 23:00:32 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGX06576; Thu, 14 Jun 2012 02:00:32 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 13 Jun 2012 22:59:50 -0700 Received: from SZXEML427-HUB.china.huawei.com (10.72.61.35) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 13 Jun 2012 22:59:55 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.45]) by szxeml427-hub.china.huawei.com ([10.72.61.35]) with mapi id 14.01.0323.003; Thu, 14 Jun 2012 13:59:45 +0800 From: Songhaibin To: Zongning Thread-Topic: [decade] WG Review of draft-ietf-decade-integration-example-03 Thread-Index: AQHNMGqZnFD1/6BJQ0yJfRNoKdEfo5b3wb2AgAF4R9CAAADtoIAADvVQ Date: Thu, 14 Jun 2012 05:59:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "decade@ietf.org" Subject: Re: [decade] WG Review of draft-ietf-decade-integration-example-03 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jun 2012 06:00:34 -0000 Hi Ning, > -----Original Message----- > From: Zongning > Sent: Thursday, June 14, 2012 10:12 AM > To: Songhaibin > Cc: decade@ietf.org; Richard Alimi > Subject: RE: [decade] WG Review of draft-ietf-decade-integration-example-= 03 >=20 > Hi, Haibin, >=20 > Thanks for your comments. Please see reply below. >=20 > > > -----Original Message----- > > > From: Songhaibin > > > Sent: Wednesday, June 13, 2012 5:30 PM > > > To: 'Richard Alimi'; decade@ietf.org > > > Subject: RE: [decade] WG Review of > draft-ietf-decade-integration-example-03 > > > > > > Thanks to Rich Alimi for a very good review. Besides that, here are s= ome > > detailed > > > comments from myself. > > > > > > In the abstract section, please do NOT refer to the working group. Th= is is also > > > applied to the first paragraph of Introduction. >=20 > [Ning]: Agree. >=20 > > > > > > In section 3, last paragraph, it mentioned "In our P2P live streaming= example, > > the > > > token is generated by INS client", I think it should be clear that th= e token is > > > generated by the INS client that is sharing its data. >=20 > [Ning]: Agree. >=20 > > > > > > Section 4.2.1, for the batch request, we may change the wording "an > > application > > > client may combine multiple requests in a single request" to "an appl= ication > > client > > > may request a batch of data objects in a single request". >=20 > [Ning]: Agree. >=20 > > > > > > Change "Larger Data Object" to "Large Data Object", otherwise, what i= s it > > > compared to? >=20 > [Ning]: Larger is compared to the typical existing P2P live streaming app= lication. > > > > > > Section 5.2, can you give the reference to Vuze messages to a more sp= ecific > > > webpage instead of "www.vuze.com"? >=20 > [Ning]: OK, I will give better reference. >=20 > > > > > > Figure 5, it is better to make it upside down, with "end user" in the= bottom, > > so as > > > to be consistent with other figures. >=20 > [Ning]: Agree. >=20 > > > > > > Section 7.4, delete more spaces before "ALTO", "End" and "CP". 2G/2G= B > > > 10G/10GB >=20 > [Ning]: OK. >=20 > > > > > > Section 8.2.2, could the authors clarify the reason behind the high n= etwork > > > resource efficiency when compared to native P2P applications? >=20 > [Ning]: OK, I will clarify this. One reason is that INS server can always= server > content to peers while in traditional P2P applications, peer have to fini= sh > downloading content before sharing with others. =20 A further explanation can be, by using INS server, a peer an immediately sh= are the object to others before it download the object to the end host, unl= ike the native P2P, a peer has to download the object, and then it can begi= n to share with others. BR, -Haibin > > > > > -----Original Message----- > > > > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On > > Behalf > > > Of > > > > Richard Alimi > > > > Sent: Sunday, May 13, 2012 2:10 AM > > > > To: decade@ietf.org > > > > Subject: [decade] WG Review of draft-ietf-decade-integration-exampl= e-03 > > > > > > > > The following is my review of > > > > draft-ietf-decade-integration-example-03. Overall, the document is > > > > much improved. It could still use some general revision for gramma= r > > > > and to make the wording more concise. > > > > > > > > Detailed review: > > > > > > > > ** Introduction > > > > > > > > s/firstly/first > > > > > > > > "we only show the feasibility of ALTO and INS without comparing to > > > > other content distribution systems at this time" > > > > - what other "content distribution systems" would be compared > > against? > > > > - if not at this time, is that planned for a future iteration of > > > > this draft (if not I'd suggest removing "at this time") > > > > > > > > ** Terminlogy > > > > > > > > add definition for "native application client" > > > > > > > > INS Service Provider > > > > - does it deploy the entire INS system, or just some servers? > > > > > > > > INS Portal > > > > - why simulated? what's a simulated portal? > > > > - don't use 'portal' in order to define the term > > > > > > > > ** INS Client API > > > > > > > > define what a 'token' is (or provide a reference) > > > > > > > > s/authorized token/authorization token/ > > > > > > > > why does the particular example (ALTO + INS) determine who generate= s > > > > the token? Is this detail necessary in the API description? > > > > > > > > ** Integration of P2P Live Streaming and INS System > > > > > > > > Introductory sentence can be simplified to just "We integrate an IN= S > > > > client into a P2P live streaming client." The rest is repetative. > > > > > > > > what does it mean to be "compatible with original P2P live streamin= g > > > > signalling"? Is it more accurate to just say that existing > > > > signallling is still used? > > > > > > > > "whose size can be application-customized according to the variable > > > > requirements of of performance or sensitive factors" - wording seem= s > > > > awkward. How about something like "the API supports variable-sized > > > > blocks to cater to different application requirements (e.g., latenc= y > > > > and throughput)." > > > > > > > > For live streaming, in what sense are they "bittorrent-like"? Piec= e > > > > exchanges? (the concept of the torrent file and piece map doesn't > > > > directly apply without modifications) > > > > > > > > "On the other hand, INS-enabled .." - remove "on the other hand" > > > > > > > > is the token exchange message the reason for the INS Client <-> INS > > > > Client line in Figure 1? If so, explain in the "Control Messages" > > > > section tha tthis does not use (or extend) the native application > > > > protocol. > > > > > > > > To what extent are the recommendations based on the fact that M=3D1= in > > > > the implementation? The stronger argument to make might be that th= e > > > > INS server may need to concurrently serve many thousands (or more) > > > > clients. > > > > > > > > "can use this range token to access all available data objects in t= he > > > > INS server" - make it clear that it isn't all objects in the serve= r, > > > > but only those to which it was permitted access > > > > > > > > The design considerations would be a lot more convincing and easier= to > > > > follow if the message flow were discussed before making the > > > > recommendations. Otherwise, the reader is less clear on the > > > > particular problem being solved. (Presenting filesharing before li= ve > > > > streaming may solve the problem.) > > > > > > > > ** Integration of P2P file sharing and INS system > > > > > > > > Is Figure 1 basically the same as Figure 2 with the exception of > > > > Figure 2 saying Vuze? If they are the same, perhaps just present t= he > > > > general architecture at the beginning of the document and say it wo= rks > > > > with both filesharing and live streaming (reuse is a good thing). > > > > > > > > Either explain why it is an "Azureous handshake" or replace it with > > > > just "handshake reply" or similar > > > > > > > > There seems to be a transition sentence missing before the details = of > > > > Figure 4 are discussed. > > > > > > > > Are ther eany additional lessons/recommendatons based on the > > > > filesharing integration? Even if there aren't, it seems like there > > > > should be some sort of concluding remarks in that section. > > > > > > > > ** Integration of ALTO and INS System for File Distribution > > > > > > > > Alto doesn't (typically) give information to end users. It gives > > > > information to applications run by those end users :) > > > > > > > > s/content servers/content providers/ > > > > > > > > alto won't help reduce bandwidth consumption for the end host (the > > > > current text seems to imply that). make it clear that it can reduce > > > > network usage within ISP > > > > > > > > s/Architecture Design/Architecture/ > > > > > > > > how does alto help CPs to upload files ot INS servers? > > > > > > > > In Figure 5, why don't End Users talk to INS Servers? It makes it > > > > look like the CP Portal and INS Portal are on the data path for > > > > downloads. Similar comment for End Users and ALTO Server. > > > > > > > > In Figure 6, why not have the Portal redirect the uploder to an INS > > > > server instead of acting as a proxy? Acting as a proxy means the > > > > portal (a server or set of servers presumably) must have an aggrega= te > > > > network capacity equal to the sum of the total upload rate that it > > > > wishes to provide to all the INS servers. By not using the proxy > > > > design, it also means the INS Portal no longer needs to define > > > > protocol messaging for communicating things like placement policies= . > > > > > > > > s/HTTP_POST/HTTP POST/ > > > > > > > > In the downloading procedure, is the user using a standard web > > > > browser? From the description, it seems like there must be some so= rt > > > > of INS extension installed in the web browser (in order to understa= nd > > > > tokens, know how to communicate with INS servers, etc). That shoul= d > > > > be stated. > > > > > > > > What is the relationship between the ISP and the INS Service Provid= er? > > > > Does the INS Service Provider have servers in multiple ISPs (in wh= ich > > > > case it would make sense to consult ALTO servers from each ISP). O= r > > > > is the INS Service Provider the same as the ISP? > > > > > > > > How is "optimal" decided? > > > > > > > > ** Test Environment and Settings > > > > > > > > Avoid using the word "cloud". They are large sets of servers availa= ble for > > use. > > > > > > > > wild-spread area -> global? > > > > > > > > how is geolocation distance computed? > > > > > > > > Figure 9 - also include where the servers were in the figure? (lik= e Figure 8) > > > > > > > > s/leeches/leechers/ > > > > > > > > would it be simpler to just assume PlanetLab Manager was part of th= e > > > > text controller and not mention it explicitly? > > > > > > > > "4G CPU" -> 4 CPU? (or, did you find 4-Ghz CPUs?) If you found a V= M > > > > with 4 billion CPUs that were halfway-decent, we should chat :) > > > > > > > > For filesharing, why is there 480MB of download traffic in the INS > > > > case but 430MB in the native case? > > > > > > > > Can an INS server always supply 94%, or only when there was a 1Gbps > > > > NIC? More specifically, does it supply 9.4Gbps with a 10Gbps NIC? > > > > > > > > it would be interesting to note what scaling issues you found passe= d > > > > 400 concurrent users at an INS server. From zongning@huawei.com Wed Jun 13 23:07:10 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95C821F85BB for ; Wed, 13 Jun 2012 23:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.599 X-Spam-Level: X-Spam-Status: No, score=-101.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ztu5BERTzVc6 for ; Wed, 13 Jun 2012 23:07:08 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 979FE21F8573 for ; Wed, 13 Jun 2012 23:07:08 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHE07974; Thu, 14 Jun 2012 02:07:08 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 13 Jun 2012 23:04:52 -0700 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 13 Jun 2012 23:04:49 -0700 Received: from SZXEML504-MBX.china.huawei.com ([169.254.4.129]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.003; Thu, 14 Jun 2012 14:04:39 +0800 From: Zongning To: Songhaibin Thread-Topic: [decade] WG Review of draft-ietf-decade-integration-example-03 Thread-Index: AQHNMGqZnFD1/6BJQ0yJfRNoKdEfo5b3wb2AgAF4R9CAAADtoIAADvVQgAA8LvA= Date: Thu, 14 Jun 2012 06:04:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "decade@ietf.org" Subject: Re: [decade] WG Review of draft-ietf-decade-integration-example-03 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jun 2012 06:07:10 -0000 Thanks, Haibin, I want to call for more comments from the list and produce a new revision s= oon. -Ning > -----Original Message----- > From: Songhaibin > Sent: Thursday, June 14, 2012 2:00 PM > To: Zongning > Cc: decade@ietf.org; Richard Alimi > Subject: RE: [decade] WG Review of draft-ietf-decade-integration-example-= 03 >=20 > Hi Ning, >=20 > > -----Original Message----- > > From: Zongning > > Sent: Thursday, June 14, 2012 10:12 AM > > To: Songhaibin > > Cc: decade@ietf.org; Richard Alimi > > Subject: RE: [decade] WG Review of draft-ietf-decade-integration-exampl= e-03 > > > > Hi, Haibin, > > > > Thanks for your comments. Please see reply below. > > > > > > -----Original Message----- > > > > From: Songhaibin > > > > Sent: Wednesday, June 13, 2012 5:30 PM > > > > To: 'Richard Alimi'; decade@ietf.org > > > > Subject: RE: [decade] WG Review of > > draft-ietf-decade-integration-example-03 > > > > > > > > Thanks to Rich Alimi for a very good review. Besides that, here are= some > > > detailed > > > > comments from myself. > > > > > > > > In the abstract section, please do NOT refer to the working group. = This is > also > > > > applied to the first paragraph of Introduction. > > > > [Ning]: Agree. > > > > > > > > > > In section 3, last paragraph, it mentioned "In our P2P live streami= ng > example, > > > the > > > > token is generated by INS client", I think it should be clear that = the token > is > > > > generated by the INS client that is sharing its data. > > > > [Ning]: Agree. > > > > > > > > > > Section 4.2.1, for the batch request, we may change the wording "an > > > application > > > > client may combine multiple requests in a single request" to "an > application > > > client > > > > may request a batch of data objects in a single request". > > > > [Ning]: Agree. > > > > > > > > > > Change "Larger Data Object" to "Large Data Object", otherwise, what= is > it > > > > compared to? > > > > [Ning]: Larger is compared to the typical existing P2P live streaming > application. >=20 > > > > > > > > Section 5.2, can you give the reference to Vuze messages to a more > specific > > > > webpage instead of "www.vuze.com"? > > > > [Ning]: OK, I will give better reference. > > > > > > > > > > Figure 5, it is better to make it upside down, with "end user" in t= he > bottom, > > > so as > > > > to be consistent with other figures. > > > > [Ning]: Agree. > > > > > > > > > > Section 7.4, delete more spaces before "ALTO", "End" and "CP". > 2G/2GB > > > > 10G/10GB > > > > [Ning]: OK. > > > > > > > > > > Section 8.2.2, could the authors clarify the reason behind the high > network > > > > resource efficiency when compared to native P2P applications? > > > > [Ning]: OK, I will clarify this. One reason is that INS server can alwa= ys server > > content to peers while in traditional P2P applications, peer have to fi= nish > > downloading content before sharing with others. >=20 > A further explanation can be, by using INS server, a peer an immediately = share > the object to others before it download the object to the end host, unlik= e the > native P2P, a peer has to download the object, and then it can begin to s= hare > with others. >=20 > BR, > -Haibin >=20 >=20 >=20 >=20 > > > > > > > -----Original Message----- > > > > > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On > > > Behalf > > > > Of > > > > > Richard Alimi > > > > > Sent: Sunday, May 13, 2012 2:10 AM > > > > > To: decade@ietf.org > > > > > Subject: [decade] WG Review of > draft-ietf-decade-integration-example-03 > > > > > > > > > > The following is my review of > > > > > draft-ietf-decade-integration-example-03. Overall, the document = is > > > > > much improved. It could still use some general revision for gram= mar > > > > > and to make the wording more concise. > > > > > > > > > > Detailed review: > > > > > > > > > > ** Introduction > > > > > > > > > > s/firstly/first > > > > > > > > > > "we only show the feasibility of ALTO and INS without comparing t= o > > > > > other content distribution systems at this time" > > > > > - what other "content distribution systems" would be compared > > > against? > > > > > - if not at this time, is that planned for a future iteration o= f > > > > > this draft (if not I'd suggest removing "at this time") > > > > > > > > > > ** Terminlogy > > > > > > > > > > add definition for "native application client" > > > > > > > > > > INS Service Provider > > > > > - does it deploy the entire INS system, or just some servers? > > > > > > > > > > INS Portal > > > > > - why simulated? what's a simulated portal? > > > > > - don't use 'portal' in order to define the term > > > > > > > > > > ** INS Client API > > > > > > > > > > define what a 'token' is (or provide a reference) > > > > > > > > > > s/authorized token/authorization token/ > > > > > > > > > > why does the particular example (ALTO + INS) determine who genera= tes > > > > > the token? Is this detail necessary in the API description? > > > > > > > > > > ** Integration of P2P Live Streaming and INS System > > > > > > > > > > Introductory sentence can be simplified to just "We integrate an = INS > > > > > client into a P2P live streaming client." The rest is repetative. > > > > > > > > > > what does it mean to be "compatible with original P2P live stream= ing > > > > > signalling"? Is it more accurate to just say that existing > > > > > signallling is still used? > > > > > > > > > > "whose size can be application-customized according to the variab= le > > > > > requirements of of performance or sensitive factors" - wording se= ems > > > > > awkward. How about something like "the API supports variable-size= d > > > > > blocks to cater to different application requirements (e.g., late= ncy > > > > > and throughput)." > > > > > > > > > > For live streaming, in what sense are they "bittorrent-like"? Pi= ece > > > > > exchanges? (the concept of the torrent file and piece map doesn'= t > > > > > directly apply without modifications) > > > > > > > > > > "On the other hand, INS-enabled .." - remove "on the other hand" > > > > > > > > > > is the token exchange message the reason for the INS Client <-> I= NS > > > > > Client line in Figure 1? If so, explain in the "Control Messages= " > > > > > section tha tthis does not use (or extend) the native application > > > > > protocol. > > > > > > > > > > To what extent are the recommendations based on the fact that M= =3D1 in > > > > > the implementation? The stronger argument to make might be that > the > > > > > INS server may need to concurrently serve many thousands (or more= ) > > > > > clients. > > > > > > > > > > "can use this range token to access all available data objects in= the > > > > > INS server" - make it clear that it isn't all objects in the ser= ver, > > > > > but only those to which it was permitted access > > > > > > > > > > The design considerations would be a lot more convincing and easi= er to > > > > > follow if the message flow were discussed before making the > > > > > recommendations. Otherwise, the reader is less clear on the > > > > > particular problem being solved. (Presenting filesharing before = live > > > > > streaming may solve the problem.) > > > > > > > > > > ** Integration of P2P file sharing and INS system > > > > > > > > > > Is Figure 1 basically the same as Figure 2 with the exception of > > > > > Figure 2 saying Vuze? If they are the same, perhaps just present= the > > > > > general architecture at the beginning of the document and say it = works > > > > > with both filesharing and live streaming (reuse is a good thing). > > > > > > > > > > Either explain why it is an "Azureous handshake" or replace it wi= th > > > > > just "handshake reply" or similar > > > > > > > > > > There seems to be a transition sentence missing before the detail= s of > > > > > Figure 4 are discussed. > > > > > > > > > > Are ther eany additional lessons/recommendatons based on the > > > > > filesharing integration? Even if there aren't, it seems like the= re > > > > > should be some sort of concluding remarks in that section. > > > > > > > > > > ** Integration of ALTO and INS System for File Distribution > > > > > > > > > > Alto doesn't (typically) give information to end users. It gives > > > > > information to applications run by those end users :) > > > > > > > > > > s/content servers/content providers/ > > > > > > > > > > alto won't help reduce bandwidth consumption for the end host (th= e > > > > > current text seems to imply that). make it clear that it can redu= ce > > > > > network usage within ISP > > > > > > > > > > s/Architecture Design/Architecture/ > > > > > > > > > > how does alto help CPs to upload files ot INS servers? > > > > > > > > > > In Figure 5, why don't End Users talk to INS Servers? It makes i= t > > > > > look like the CP Portal and INS Portal are on the data path for > > > > > downloads. Similar comment for End Users and ALTO Server. > > > > > > > > > > In Figure 6, why not have the Portal redirect the uploder to an I= NS > > > > > server instead of acting as a proxy? Acting as a proxy means the > > > > > portal (a server or set of servers presumably) must have an aggre= gate > > > > > network capacity equal to the sum of the total upload rate that i= t > > > > > wishes to provide to all the INS servers. By not using the proxy > > > > > design, it also means the INS Portal no longer needs to define > > > > > protocol messaging for communicating things like placement polici= es. > > > > > > > > > > s/HTTP_POST/HTTP POST/ > > > > > > > > > > In the downloading procedure, is the user using a standard web > > > > > browser? From the description, it seems like there must be some = sort > > > > > of INS extension installed in the web browser (in order to unders= tand > > > > > tokens, know how to communicate with INS servers, etc). That sho= uld > > > > > be stated. > > > > > > > > > > What is the relationship between the ISP and the INS Service Prov= ider? > > > > > Does the INS Service Provider have servers in multiple ISPs (in = which > > > > > case it would make sense to consult ALTO servers from each ISP). = Or > > > > > is the INS Service Provider the same as the ISP? > > > > > > > > > > How is "optimal" decided? > > > > > > > > > > ** Test Environment and Settings > > > > > > > > > > Avoid using the word "cloud". They are large sets of servers avai= lable for > > > use. > > > > > > > > > > wild-spread area -> global? > > > > > > > > > > how is geolocation distance computed? > > > > > > > > > > Figure 9 - also include where the servers were in the figure? (l= ike > Figure 8) > > > > > > > > > > s/leeches/leechers/ > > > > > > > > > > would it be simpler to just assume PlanetLab Manager was part of = the > > > > > text controller and not mention it explicitly? > > > > > > > > > > "4G CPU" -> 4 CPU? (or, did you find 4-Ghz CPUs?) If you found a= VM > > > > > with 4 billion CPUs that were halfway-decent, we should chat :) > > > > > > > > > > For filesharing, why is there 480MB of download traffic in the IN= S > > > > > case but 430MB in the native case? > > > > > > > > > > Can an INS server always supply 94%, or only when there was a 1Gb= ps > > > > > NIC? More specifically, does it supply 9.4Gbps with a 10Gbps NIC= ? > > > > > > > > > > it would be interesting to note what scaling issues you found pas= sed > > > > > 400 concurrent users at an INS server. From haibin.song@huawei.com Wed Jun 13 23:44:05 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7229721F86F9 for ; Wed, 13 Jun 2012 23:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.349 X-Spam-Level: X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0e4g6baqAbL for ; Wed, 13 Jun 2012 23:44:05 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id B750321F86F8 for ; Wed, 13 Jun 2012 23:44:04 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHE09638; Thu, 14 Jun 2012 02:44:04 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 13 Jun 2012 23:43:04 -0700 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 13 Jun 2012 23:43:02 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.45]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0323.003; Thu, 14 Jun 2012 14:42:56 +0800 From: Songhaibin To: "decade@ietf.org" Thread-Topic: Open discussion: Application agnostic content distribution Thread-Index: Ac1J+OyLi9294JYgSC2pI1YHMlXEcQ== Date: Thu, 14 Jun 2012 06:42:56 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: CCw= A4yu BT8V BxPF Cedo Cwkd D1Go EPwp FOKi FZfa GR4K Glo4 H/bL I7Q8 JxW6 LBrr; 1; ZABlAGMAYQBkAGUAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {ACC47436-0C61-4233-BF6E-529F180DB174}; aABhAGkAYgBpAG4ALgBzAG8AbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Thu, 14 Jun 2012 06:42:53 GMT; TwBwAGUAbgAgAGQAaQBzAGMAdQBzAHMAaQBvAG4AOgAgAEEAcABwAGwAaQBjAGEAdABpAG8AbgAgAGEAZwBuAG8AcwB0AGkAYwAgAGMAbwBuAHQAZQBuAHQAIABkAGkAcwB0AHIAaQBiAHUAdABpAG8AbgA= x-cr-puzzleid: {ACC47436-0C61-4233-BF6E-529F180DB174} x-originating-ip: [10.138.41.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [decade] Open discussion: Application agnostic content distribution X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jun 2012 06:44:05 -0000 Hi guys, I think this is a very general and open question to all of the working grou= p. Which is also somewhat the high level goal of the working group. In orde= r to do a general application agnostic content distribution platform inside= the network, and the content distribution applications will be likely to u= se it. what kind of functions and components it should support? Or more gen= eral, what does the platform need? If you can answer with use case, that wo= uld be good. The architecture document is a good base. But I do not want th= e limit. BR, -Haibin (as individual contributor) From haibin.song@huawei.com Thu Jun 14 02:53:48 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB1421F8663 for ; Thu, 14 Jun 2012 02:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Bvpd4kFm2Fx for ; Thu, 14 Jun 2012 02:53:48 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB0F21F865F for ; Thu, 14 Jun 2012 02:53:48 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGX18367; Thu, 14 Jun 2012 05:53:47 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 14 Jun 2012 02:53:10 -0700 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 14 Jun 2012 02:53:15 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.45]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Thu, 14 Jun 2012 17:53:10 +0800 From: Songhaibin To: "decade@ietf.org" Thread-Topic: [ipr-announce] IPR Disclosure: Larry Masinter's Statement about IPR related to draft-farrell-decade-ni-06 belonging to Xerox Corporation Thread-Index: AQHNLTU7nqROpUCLxkW9NU9rONUfYJb5zIkg Date: Thu, 14 Jun 2012 09:53:10 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [decade] FW: [ipr-announce] IPR Disclosure: Larry Masinter's Statement about IPR related to draft-farrell-decade-ni-06 belonging to Xerox Corporation X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jun 2012 09:53:49 -0000 > -----Original Message----- > From: ipr-announce-bounces@ietf.org [mailto:ipr-announce-bounces@ietf.org= ] > On Behalf Of IETF Secretariat > Sent: Wednesday, May 09, 2012 12:11 AM > To: stephen.farrell@cs.tcd.ie; cdannewitz@upb.de; Borje.Ohlman@ericsson.c= om; > kutscher@neclab.eu; philliph@comodo.com; ari.keranen@ericsson.com > Cc: barryleiba@computer.org; ipr-announce@ietf.org > Subject: [ipr-announce] IPR Disclosure: Larry Masinter's Statement about = IPR > related to draft-farrell-decade-ni-06 belonging to Xerox Corporation >=20 >=20 > Dear Stephen Farrell, Christian Dannewitz, Borje Ohlman, Dirk Kutscher, P= hillip > Hallam-Baker, Ari Keranen: >=20 > An IPR disclosure that pertains to your Internet-Draft entitled "Naming = Things > with Hashes" (draft-farrell-decade-ni) was submitted to the IETF Secretar= iat on > 2012-05-08 and has been posted on the "IETF Page of Intellectual Property= Rights > Disclosures" (https://datatracker.ietf.org/ipr/1775/). The title of the I= PR > disclosure is "Larry Masinter's Statement about IPR related to draft-farr= ell- > decade-ni-06 belonging to Xerox Corporation.""); >=20 > The IETF Secretariat >=20 > _______________________________________________ > ipr-announce mailing list > ipr-announce@ietf.org > https://www.ietf.org/mailman/listinfo/ipr-announce From stephen.farrell@cs.tcd.ie Thu Jun 14 03:19:22 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3190921F86B2 for ; Thu, 14 Jun 2012 03:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBPUjdSyGS1J for ; Thu, 14 Jun 2012 03:19:21 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA9521F8673 for ; Thu, 14 Jun 2012 03:19:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id B813D1717FF; Thu, 14 Jun 2012 11:19:18 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h=date :subject:from:x-mailer:message-id:content-type :content-transfer-encoding:mime-version:in-reply-to:references :received:received:x-virus-scanned; s=cs; t=1339669158; bh=ffGAv S/eZb673VPYv0icnhGpVi5o0CAFpWKMcd/poGc=; b=SzbaWkdtCIcCm3JTamQSL xA+AVs8WKv6CRtwSNkNUIYDv+z/O3ZXeFvS2c/fsAuTAvl3vgXCfM62zB5fVhNcd 4ZwmKu4QGLG0gqBG5q+bO/s5Ddt1OHc7OrDpli1LCLPf8K/QfKJBU5SCgD+IHmDP WJeDzfs/sle/DSgdoCmFsM1+xl1ab4fk3gH8I4Zs16WHUtSJt8ZYSeAFkcT97RbF /IPyzO98d+puv93GXsKgEuPz7dd0cB0bJIEFnA6BvhRbqxAuZeeFVankf7pQtziE HiqNpBgXrQpgyenUDhUMFoha4OF0EVyFzNWPdEXQtwRhDqJ6UQgpczhqgxvIf2zm Q== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id EX9f1hPkvEtS; Thu, 14 Jun 2012 11:19:18 +0100 (IST) Received: from [10.37.133.148] (unknown [62.40.36.13]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id D70A6171471; Thu, 14 Jun 2012 11:19:09 +0100 (IST) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9B206) From: Stephen Farrell Date: Thu, 14 Jun 2012 11:18:21 +0100 To: Songhaibin Cc: "decade@ietf.org" Subject: Re: [decade] FW: [ipr-announce] IPR Disclosure: Larry Masinter's Statement about IPR related to draft-farrell-decade-ni-06 belonging to Xerox Corporation X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jun 2012 10:19:22 -0000 Hi, People of course need to do their own checking, but I believe that the paten= t concerned was abandoned (not renewed, whatever is the right term), Cheers, S On 14 Jun 2012, at 10:53, Songhaibin wrote: >=20 >=20 >> -----Original Message----- >> From: ipr-announce-bounces@ietf.org [mailto:ipr-announce-bounces@ietf.org= ] >> On Behalf Of IETF Secretariat >> Sent: Wednesday, May 09, 2012 12:11 AM >> To: stephen.farrell@cs.tcd.ie; cdannewitz@upb.de; Borje.Ohlman@ericsson.c= om; >> kutscher@neclab.eu; philliph@comodo.com; ari.keranen@ericsson.com >> Cc: barryleiba@computer.org; ipr-announce@ietf.org >> Subject: [ipr-announce] IPR Disclosure: Larry Masinter's Statement about I= PR >> related to draft-farrell-decade-ni-06 belonging to Xerox Corporation >>=20 >>=20 >> Dear Stephen Farrell, Christian Dannewitz, Borje Ohlman, Dirk Kutscher, P= hillip >> Hallam-Baker, Ari Keranen: >>=20 >> An IPR disclosure that pertains to your Internet-Draft entitled "Naming T= hings >> with Hashes" (draft-farrell-decade-ni) was submitted to the IETF Secretar= iat on >> 2012-05-08 and has been posted on the "IETF Page of Intellectual Property= Rights >> Disclosures" (https://datatracker.ietf.org/ipr/1775/). The title of the I= PR >> disclosure is "Larry Masinter's Statement about IPR related to draft-farr= ell- >> decade-ni-06 belonging to Xerox Corporation.""); >>=20 >> The IETF Secretariat >>=20 >> _______________________________________________ >> ipr-announce mailing list >> ipr-announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ipr-announce From cabo@tzi.org Thu Jun 14 03:44:54 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62ADF21F86BA for ; Thu, 14 Jun 2012 03:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.969 X-Spam-Level: X-Spam-Status: No, score=-106.969 tagged_above=-999 required=5 tests=[AWL=-0.720, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImFjexyrOD9f for ; Thu, 14 Jun 2012 03:44:53 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 755DE21F86B9 for ; Thu, 14 Jun 2012 03:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q5EAijEp015419; Thu, 14 Jun 2012 12:44:45 +0200 (CEST) Received: from [192.168.217.105] (p54899DA7.dip.t-dialin.net [84.137.157.167]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 98D1CFD0; Thu, 14 Jun 2012 12:44:45 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Thu, 14 Jun 2012 12:44:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5E8F275B-712A-4A65-888B-48E114C8BD3C@tzi.org> References: To: Stephen Farrell X-Mailer: Apple Mail (2.1278) Cc: decade@ietf.org Subject: Re: [decade] FW: [ipr-announce] IPR Disclosure: Larry Masinter's Statement about IPR related to draft-farrell-decade-ni-06 belonging to Xerox Corporation X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jun 2012 10:44:54 -0000 On Jun 14, 2012, at 12:18, Stephen Farrell wrote: > People of course need to do their own checking Indeed. Let me just say that, as a WG member, I believe disclosure 1775 does not = pose an obstacle in any way to progressing this document as an IETF = standards-track document or to using the technology in the DECADE = framework. Thanks to Larry for having brought this information to our attention; it = is important for the IETF process that people fulfill their duties as of = BCP 79 in a timely way. Gr=FC=DFe, Carsten From stephen.farrell@cs.tcd.ie Thu Jun 14 04:16:16 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE47321F86B2 for ; Thu, 14 Jun 2012 04:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlNO5s5EwUvQ for ; Thu, 14 Jun 2012 04:16:15 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4B021F86AA for ; Thu, 14 Jun 2012 04:16:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 943781717F1; Thu, 14 Jun 2012 12:16:14 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1339672574; bh=OY9lctarGJ9+yI IFdq5DwByFZAmowg3+oDFYz8RZqyw=; b=qpQJmdgNZYdxVvwf+RUiAwscLdkp+x D+pxVgDaEakdk6O+dscUr5KHRtJJNyqslnRU4FTBWz+XpYT1P1Jku34xjKaqFkQ9 i6NSY9qiPtW2BqJSAZP9GbHcXiQLBBngDziAVdVzlFz8tZ8eLVz2agr5YNcpq0vb KHA6+MjYYAhDTuCneVZXUBjMkLZdHFZoYeOGlG4fA/umFDgzl6YESU0xT0laMttS qfvxzWpv3W/BUfpjynnpdp49/yToiuc3VE9Lwy6NM3Ck6x9MfYQuDretgz3rCj5G ErZtjnVt3HF0b98b4t/d3wKSRMVysmxpIYmEzYPOkARKW1YJbf+SwV4A== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id U+b1TbWaovnY; Thu, 14 Jun 2012 12:16:14 +0100 (IST) Received: from [IPv6:2001:770:10:203:a85b:571c:23b6:7a83] (unknown [IPv6:2001:770:10:203:a85b:571c:23b6:7a83]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 155A9171538; Thu, 14 Jun 2012 12:16:14 +0100 (IST) Message-ID: <4FD9C7FD.8060802@cs.tcd.ie> Date: Thu, 14 Jun 2012 12:16:13 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Carsten Bormann References: <5E8F275B-712A-4A65-888B-48E114C8BD3C@tzi.org> In-Reply-To: <5E8F275B-712A-4A65-888B-48E114C8BD3C@tzi.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: decade@ietf.org Subject: Re: [decade] FW: [ipr-announce] IPR Disclosure: Larry Masinter's Statement about IPR related to draft-farrell-decade-ni-06 belonging to Xerox Corporation X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jun 2012 11:16:17 -0000 On 06/14/2012 11:44 AM, Carsten Bormann wrote: > On Jun 14, 2012, at 12:18, Stephen Farrell wrote: > >> People of course need to do their own checking > > Indeed. > > Let me just say that, as a WG member, I believe disclosure 1775 does not pose an obstacle in any way to progressing this document as an IETF standards-track document or to using the technology in the DECADE framework. > > Thanks to Larry for having brought this information to our attention; it is important for the IETF process that people fulfill their duties as of BCP 79 in a timely way. Fully agree, Cheers, S. > Grüße, Carsten > From internet-drafts@ietf.org Thu Jun 14 07:37:32 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DADD421F86D1; Thu, 14 Jun 2012 07:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BH+NKyVDwo3V; Thu, 14 Jun 2012 07:37:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5578121F86A8; Thu, 14 Jun 2012 07:37:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120614143732.20112.42681.idtracker@ietfa.amsl.com> Date: Thu, 14 Jun 2012 07:37:32 -0700 Cc: decade@ietf.org Subject: [decade] I-D Action: draft-ietf-decade-arch-07.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jun 2012 14:37:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Decoupled Application Data Enroute Workin= g Group of the IETF. Title : DECADE Architecture Author(s) : Richard Alimi Akbar Rahman Dirk Kutscher Y. Richard Yang Filename : draft-ietf-decade-arch-07.txt Pages : 33 Date : 2012-06-14 Abstract: Content Distribution Applications (e.g., Peer-to-Peer applications) are widely used on the Internet and make up a large portion of the traffic in many networks. One technique to improve the network efficiency of these applications is to introduce storage capabilities within the networks; this is the capability provided by a DECADE (DECoupled Application Data Enroute) compatible system. This document presents an architecture, discusses the underlying principles, and identifies key functionalities required for introducing a DECADE-compatible in-network storage system. In addition, some examples are given to illustrate these concepts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-decade-arch There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-decade-arch-07 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-decade-arch-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Akbar.Rahman@InterDigital.com Thu Jun 14 07:40:16 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE18621F86A8 for ; Thu, 14 Jun 2012 07:40:16 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wcm7FEdHcBlb for ; Thu, 14 Jun 2012 07:40:16 -0700 (PDT) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id DE80921F8671 for ; Thu, 14 Jun 2012 07:40:15 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Jun 2012 10:40:15 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 14 Jun 2012 10:40:14 -0400 Message-ID: In-Reply-To: <20120614143732.20112.42681.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] I-D Action: draft-ietf-decade-arch-07.txt Thread-Index: Ac1KOz4r32aCTCmdQNSjEMDfDUQtuwAAA4JQ References: <20120614143732.20112.42681.idtracker@ietfa.amsl.com> From: "Rahman, Akbar" To: "Songhaibin" , "Woundy, Richard" X-OriginalArrivalTime: 14 Jun 2012 14:40:15.0065 (UTC) FILETIME=[9C5F9C90:01CD4A3B] Cc: decade@ietf.org Subject: Re: [decade] I-D Action: draft-ietf-decade-arch-07.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jun 2012 14:40:17 -0000 SGkgSGFpYmluL1JpY2gsDQoNCg0KV2UgaGF2ZSBzdWJtaXR0ZWQgdGhlIGxhdGVzdCBERUNBREUg QXJjaGl0ZWN0dXJlIEktRCB0byBhZGRyZXNzIHRoZSByZW1haW5pbmcgaXNzdWVzIG9wZW4gZnJv bSB0aGUgSUVTRyByZXZpZXdzLiAgIElmIHRoaXMgdmVyc2lvbiBsb29rcyBva2F5IHRvIHlvdSB0 aGVuIHBsZWFzZSBzdGFydCB0aGUgbmV3IFdHTEMgYXQgeW91ciBjb252ZW5pZW5jZS4NCg0KDQpU byByZS1jYXAgd2UgaGF2ZSBkb25lIHRoZSBmb2xsb3dpbmcgcmV2aXNpb25zIGluIHRoZSBsYXN0 IGZldyBtb250aHMgdG8gYWRkcmVzcyB0aGUgSUVTRyByZXZpZXcgY29tbWVudHM6DQoNCuKAoglS ZXYuIDA3DQoJbwlBZGRyZXNzZWQgaXNzdWVzIHJhaXNlZCBieSBEYXZlIENyb2NrZXIgb24gUHJv YmxlbSBTdGF0ZW1lbnQgSS1EIGFuZCBSZXF1aXJlbWVudHMgSS1EIHRoYXQgd2VyZSBhbHNvIGFw cGxpY2FibGUgdG8gdGhlIEFyY2hpdGVjdHVyZSBJLUQNCg0K4oCiCVJldi4gMDYNCglvCUFkZHJl c3NlZCB0aGUgcmVtYWluaW5nIG9wZW4gaXNzdWVzIGZyb20gQ2Fyc3RlbiBCb3JtYW5uIGFuZCBE YXZlIEhhcnJpbmd0b24NCg0K4oCiCVJldi4gMDUNCglvCUFkZHJlc3NlZCBtYWpvcml0eSBvZiBp c3N1ZXMgcmFpc2VkIGJ5IENhcnN0ZW4gQm9ybWFubiBhbmQgRGF2ZSBIYXJyaW5ndG9uDQoNCuKA oglSZXYuIDA0DQoJbwlWZXJzaW9uIHNlbnQgdG8gSUVTRw0KDQoNCg0KU2luY2VyZWx5LA0KDQoN Cg0KQWtiYXIgL1JpY2ggQWxpbWkvRGlyayBLdXRzY2hlci9SaWNoYXJkIFlhbmcNCg0KDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBkZWNhZGUtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOmRlY2FkZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgaW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnDQpTZW50OiBUaHVyc2RheSwgSnVuZSAxNCwgMjAxMiAxMDozOCBBTQ0KVG86 IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KQ2M6IGRlY2FkZUBpZXRmLm9yZw0KU3ViamVjdDogW2Rl Y2FkZV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1kZWNhZGUtYXJjaC0wNy50eHQNCg0KDQpBIE5l dyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1E cmFmdHMgZGlyZWN0b3JpZXMuDQogVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgRGVj b3VwbGVkIEFwcGxpY2F0aW9uIERhdGEgRW5yb3V0ZSBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRG Lg0KDQoJVGl0bGUgICAgICAgICAgIDogREVDQURFIEFyY2hpdGVjdHVyZQ0KCUF1dGhvcihzKSAg ICAgICA6IFJpY2hhcmQgQWxpbWkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgQWtiYXIgUmFo bWFuDQogICAgICAgICAgICAgICAgICAgICAgICAgIERpcmsgS3V0c2NoZXINCiAgICAgICAgICAg ICAgICAgICAgICAgICAgWS4gUmljaGFyZCBZYW5nDQoJRmlsZW5hbWUgICAgICAgIDogZHJhZnQt aWV0Zi1kZWNhZGUtYXJjaC0wNy50eHQNCglQYWdlcyAgICAgICAgICAgOiAzMw0KCURhdGUgICAg ICAgICAgICA6IDIwMTItMDYtMTQNCg0KQWJzdHJhY3Q6DQogICBDb250ZW50IERpc3RyaWJ1dGlv biBBcHBsaWNhdGlvbnMgKGUuZy4sIFBlZXItdG8tUGVlciBhcHBsaWNhdGlvbnMpDQogICBhcmUg d2lkZWx5IHVzZWQgb24gdGhlIEludGVybmV0IGFuZCBtYWtlIHVwIGEgbGFyZ2UgcG9ydGlvbiBv ZiB0aGUNCiAgIHRyYWZmaWMgaW4gbWFueSBuZXR3b3Jrcy4gIE9uZSB0ZWNobmlxdWUgdG8gaW1w cm92ZSB0aGUgbmV0d29yaw0KICAgZWZmaWNpZW5jeSBvZiB0aGVzZSBhcHBsaWNhdGlvbnMgaXMg dG8gaW50cm9kdWNlIHN0b3JhZ2UgY2FwYWJpbGl0aWVzDQogICB3aXRoaW4gdGhlIG5ldHdvcmtz OyB0aGlzIGlzIHRoZSBjYXBhYmlsaXR5IHByb3ZpZGVkIGJ5IGEgREVDQURFDQogICAoREVDb3Vw bGVkIEFwcGxpY2F0aW9uIERhdGEgRW5yb3V0ZSkgY29tcGF0aWJsZSBzeXN0ZW0uICBUaGlzDQog ICBkb2N1bWVudCBwcmVzZW50cyBhbiBhcmNoaXRlY3R1cmUsIGRpc2N1c3NlcyB0aGUgdW5kZXJs eWluZw0KICAgcHJpbmNpcGxlcywgYW5kIGlkZW50aWZpZXMga2V5IGZ1bmN0aW9uYWxpdGllcyBy ZXF1aXJlZCBmb3INCiAgIGludHJvZHVjaW5nIGEgREVDQURFLWNvbXBhdGlibGUgaW4tbmV0d29y ayBzdG9yYWdlIHN5c3RlbS4gIEluDQogICBhZGRpdGlvbiwgc29tZSBleGFtcGxlcyBhcmUgZ2l2 ZW4gdG8gaWxsdXN0cmF0ZSB0aGVzZSBjb25jZXB0cy4NCg0KDQoNClRoZSBJRVRGIGRhdGF0cmFj a2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kZWNhZGUtYXJjaA0KDQpUaGVyZSdzIGFsc28gYSBodG1s aXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtZGVjYWRlLWFyY2gtMDcNCg0KQSBkaWZmIGZyb20gcHJldmlvdXMgdmVyc2lvbiBp cyBhdmFpbGFibGUgYXQ6DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0 LWlldGYtZGVjYWRlLWFyY2gtMDcNCg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxh YmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzLw0KDQo= From Akbar.Rahman@InterDigital.com Thu Jun 14 07:59:18 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E1B21F8681 for ; Thu, 14 Jun 2012 07:59:18 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vR34OewJjRX for ; Thu, 14 Jun 2012 07:59:17 -0700 (PDT) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6811221F86CF for ; Thu, 14 Jun 2012 07:59:17 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Jun 2012 10:59:16 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 14 Jun 2012 10:59:15 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] I-D Action: draft-ietf-decade-arch-07.txt Thread-Index: Ac1KOz4r32aCTCmdQNSjEMDfDUQtuwAAA4JQAACo1sA= References: <20120614143732.20112.42681.idtracker@ietfa.amsl.com> From: "Rahman, Akbar" To: "Songhaibin" , "Woundy, Richard" X-OriginalArrivalTime: 14 Jun 2012 14:59:16.0956 (UTC) FILETIME=[44FE59C0:01CD4A3E] Cc: decade@ietf.org Subject: Re: [decade] I-D Action: draft-ietf-decade-arch-07.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jun 2012 14:59:18 -0000 QW5kIGZvciB5b3VyIGNvbnZlbmllbmNlLCBoZXJlIHlvdSBjYW4gZWFzaWx5IHNlZSBhbGwgdGhl IGNoYW5nZXMgYmV0d2VlbiByZXYtMDQgJiByZXYtMDcgKHVzaW5nIHRoZSBoYW5keSBEaWZmIHRv b2wpOg0KDQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy8vcmZjZGlmZj91cmwxPWh0dHA6Ly90b29s cy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLWRlY2FkZS1hcmNoLTA0LnR4dCZ1cmwyPWh0dHA6Ly90 b29scy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLWRlY2FkZS1hcmNoLTA3LnR4dA0KDQoNCg0KDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBkZWNhZGUtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOmRlY2FkZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUmFobWFuLCBB a2Jhcg0KU2VudDogVGh1cnNkYXksIEp1bmUgMTQsIDIwMTIgMTA6NDAgQU0NClRvOiBTb25naGFp YmluOyBXb3VuZHksIFJpY2hhcmQNCkNjOiBkZWNhZGVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb ZGVjYWRlXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRlY2FkZS1hcmNoLTA3LnR4dA0KDQpIaSBI YWliaW4vUmljaCwNCg0KDQpXZSBoYXZlIHN1Ym1pdHRlZCB0aGUgbGF0ZXN0IERFQ0FERSBBcmNo aXRlY3R1cmUgSS1EIHRvIGFkZHJlc3MgdGhlIHJlbWFpbmluZyBpc3N1ZXMgb3BlbiBmcm9tIHRo ZSBJRVNHIHJldmlld3MuICAgSWYgdGhpcyB2ZXJzaW9uIGxvb2tzIG9rYXkgdG8geW91IHRoZW4g cGxlYXNlIHN0YXJ0IHRoZSBuZXcgV0dMQyBhdCB5b3VyIGNvbnZlbmllbmNlLg0KDQoNClRvIHJl LWNhcCB3ZSBoYXZlIGRvbmUgdGhlIGZvbGxvd2luZyByZXZpc2lvbnMgaW4gdGhlIGxhc3QgZmV3 IG1vbnRocyB0byBhZGRyZXNzIHRoZSBJRVNHIHJldmlldyBjb21tZW50czoNCg0K4oCiCVJldi4g MDcNCglvCUFkZHJlc3NlZCBpc3N1ZXMgcmFpc2VkIGJ5IERhdmUgQ3JvY2tlciBvbiBQcm9ibGVt IFN0YXRlbWVudCBJLUQgYW5kIFJlcXVpcmVtZW50cyBJLUQgdGhhdCB3ZXJlIGFsc28gYXBwbGlj YWJsZSB0byB0aGUgQXJjaGl0ZWN0dXJlIEktRA0KDQrigKIJUmV2LiAwNg0KCW8JQWRkcmVzc2Vk IHRoZSByZW1haW5pbmcgb3BlbiBpc3N1ZXMgZnJvbSBDYXJzdGVuIEJvcm1hbm4gYW5kIERhdmUg SGFycmluZ3Rvbg0KDQrigKIJUmV2LiAwNQ0KCW8JQWRkcmVzc2VkIG1ham9yaXR5IG9mIGlzc3Vl cyByYWlzZWQgYnkgQ2Fyc3RlbiBCb3JtYW5uIGFuZCBEYXZlIEhhcnJpbmd0b24NCg0K4oCiCVJl di4gMDQNCglvCVZlcnNpb24gc2VudCB0byBJRVNHDQoNCg0KDQpTaW5jZXJlbHksDQoNCg0KDQpB a2JhciAvUmljaCBBbGltaS9EaXJrIEt1dHNjaGVyL1JpY2hhcmQgWWFuZw0KDQoNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGRlY2FkZS1ib3VuY2VzQGlldGYub3JnIFttYWls dG86ZGVjYWRlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmcNClNlbnQ6IFRodXJzZGF5LCBKdW5lIDE0LCAyMDEyIDEwOjM4IEFNDQpUbzogaS1k LWFubm91bmNlQGlldGYub3JnDQpDYzogZGVjYWRlQGlldGYub3JnDQpTdWJqZWN0OiBbZGVjYWRl XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRlY2FkZS1hcmNoLTA3LnR4dA0KDQoNCkEgTmV3IElu dGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0 cyBkaXJlY3Rvcmllcy4NCiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBEZWNvdXBs ZWQgQXBwbGljYXRpb24gRGF0YSBFbnJvdXRlIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQoN CglUaXRsZSAgICAgICAgICAgOiBERUNBREUgQXJjaGl0ZWN0dXJlDQoJQXV0aG9yKHMpICAgICAg IDogUmljaGFyZCBBbGltaQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBBa2JhciBSYWhtYW4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgRGlyayBLdXRzY2hlcg0KICAgICAgICAgICAgICAg ICAgICAgICAgICBZLiBSaWNoYXJkIFlhbmcNCglGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRm LWRlY2FkZS1hcmNoLTA3LnR4dA0KCVBhZ2VzICAgICAgICAgICA6IDMzDQoJRGF0ZSAgICAgICAg ICAgIDogMjAxMi0wNi0xNA0KDQpBYnN0cmFjdDoNCiAgIENvbnRlbnQgRGlzdHJpYnV0aW9uIEFw cGxpY2F0aW9ucyAoZS5nLiwgUGVlci10by1QZWVyIGFwcGxpY2F0aW9ucykNCiAgIGFyZSB3aWRl bHkgdXNlZCBvbiB0aGUgSW50ZXJuZXQgYW5kIG1ha2UgdXAgYSBsYXJnZSBwb3J0aW9uIG9mIHRo ZQ0KICAgdHJhZmZpYyBpbiBtYW55IG5ldHdvcmtzLiAgT25lIHRlY2huaXF1ZSB0byBpbXByb3Zl IHRoZSBuZXR3b3JrDQogICBlZmZpY2llbmN5IG9mIHRoZXNlIGFwcGxpY2F0aW9ucyBpcyB0byBp bnRyb2R1Y2Ugc3RvcmFnZSBjYXBhYmlsaXRpZXMNCiAgIHdpdGhpbiB0aGUgbmV0d29ya3M7IHRo aXMgaXMgdGhlIGNhcGFiaWxpdHkgcHJvdmlkZWQgYnkgYSBERUNBREUNCiAgIChERUNvdXBsZWQg QXBwbGljYXRpb24gRGF0YSBFbnJvdXRlKSBjb21wYXRpYmxlIHN5c3RlbS4gIFRoaXMNCiAgIGRv Y3VtZW50IHByZXNlbnRzIGFuIGFyY2hpdGVjdHVyZSwgZGlzY3Vzc2VzIHRoZSB1bmRlcmx5aW5n DQogICBwcmluY2lwbGVzLCBhbmQgaWRlbnRpZmllcyBrZXkgZnVuY3Rpb25hbGl0aWVzIHJlcXVp cmVkIGZvcg0KICAgaW50cm9kdWNpbmcgYSBERUNBREUtY29tcGF0aWJsZSBpbi1uZXR3b3JrIHN0 b3JhZ2Ugc3lzdGVtLiAgSW4NCiAgIGFkZGl0aW9uLCBzb21lIGV4YW1wbGVzIGFyZSBnaXZlbiB0 byBpbGx1c3RyYXRlIHRoZXNlIGNvbmNlcHRzLg0KDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIg c3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLWRlY2FkZS1hcmNoDQoNClRoZXJlJ3MgYWxzbyBhIGh0bWxpemVk IHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1kZWNhZGUtYXJjaC0wNw0KDQpBIGRpZmYgZnJvbSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2 YWlsYWJsZSBhdDoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0 Zi1kZWNhZGUtYXJjaC0wNw0KDQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUg YnkgYW5vbnltb3VzIEZUUCBhdDoNCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv DQoNCg== From Akbar.Rahman@InterDigital.com Thu Jun 14 10:19:34 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C728D21F86CF for ; Thu, 14 Jun 2012 10:19:34 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cp+A5E7DcFpo for ; Thu, 14 Jun 2012 10:19:34 -0700 (PDT) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id 137D121F8669 for ; Thu, 14 Jun 2012 10:19:33 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Jun 2012 13:19:33 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 14 Jun 2012 13:19:32 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [decade] Open discussion: Application agnostic content distribution Thread-Index: Ac1J+OyLi9294JYgSC2pI1YHMlXEcQAVsvtA References: From: "Rahman, Akbar" To: "Songhaibin" X-OriginalArrivalTime: 14 Jun 2012 17:19:33.0380 (UTC) FILETIME=[DD92BC40:01CD4A51] Cc: decade@ietf.org Subject: Re: [decade] Open discussion: Application agnostic content distribution X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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, 14 Jun 2012 17:19:35 -0000 Hi Haibin, I agree that this is a very important question that you are asking. In terms of an important use case, I think that we should consider if DECADE can be applied to work as in-network storage as part of a cloud computing environment. To me this would be the most "general application agnostic content distribution platform inside the network" that we could aim for. I remember that in some of the previous WG discussions, we considered the possibility of supporting the cloud computing model as part of the WG re-charter. I for one would vote in favor of this. Akbar -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Songhaibin Sent: Thursday, June 14, 2012 2:43 AM To: decade@ietf.org Subject: [decade] Open discussion: Application agnostic content distribution Hi guys, I think this is a very general and open question to all of the working group. Which is also somewhat the high level goal of the working group. In order to do a general application agnostic content distribution platform inside the network, and the content distribution applications will be likely to use it. what kind of functions and components it should support? Or more general, what does the platform need? If you can answer with use case, that would be good. The architecture document is a good base. But I do not want the limit. BR, -Haibin (as individual contributor) From yang.r.yang@gmail.com Thu Jun 14 17:54:16 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3FC11E80A0 for ; Thu, 14 Jun 2012 17:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDdpxxMtxp4V for ; Thu, 14 Jun 2012 17:54:15 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id E748611E809F for ; Thu, 14 Jun 2012 17:54:14 -0700 (PDT) Received: by bkty8 with SMTP id y8so2193700bkt.31 for ; Thu, 14 Jun 2012 17:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=mQHBo0cj4K4nZDJp8m52D+SvLqrrIvXFgr4zv1M/g68=; b=i8lUPokp4ETr5PocszQwyGc66el4OkLMzNaUsw6ik6YR1GwvTTOIVstbUqjgiX3vZU k8U/sRDtO9QlYB1u8aur7R5RoA+D7YeNrewYlJLVkLwE3mNTAOC25lB3TjchvtjoTE/g TPEGIJIu+01lQ3l+E2jp3dqS3OHA43yRH85PfZ9tEKy344ZqkScurJjIkzOia/aqkAYV ExzpncY2GUsw3WyN3aM7dTdeo+3INpETjgZufCK6A3wGwNyDKqyycSkHuHM7ars+/0d9 vcoKaSrEPvjzPZpsrJBSpRETueqNjxyx315ElDDFLjGshH8smXAlSC6++01zLw8O6WqW amCg== MIME-Version: 1.0 Received: by 10.204.154.80 with SMTP id n16mr2130759bkw.112.1339721654007; Thu, 14 Jun 2012 17:54:14 -0700 (PDT) Sender: yang.r.yang@gmail.com Received: by 10.204.186.16 with HTTP; Thu, 14 Jun 2012 17:54:13 -0700 (PDT) In-Reply-To: References: Date: Thu, 14 Jun 2012 20:54:13 -0400 X-Google-Sender-Auth: aSx60Gn6mxu5mkUjSI3L6RL4FUk Message-ID: From: "Y. Richard Yang" To: "Rahman, Akbar" Content-Type: multipart/alternative; boundary=0015175ccf3e48f8c704c2784105 Cc: "decade@ietf.org" Subject: Re: [decade] Open discussion: Application agnostic content distribution X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jun 2012 00:56:26 -0000 --0015175ccf3e48f8c704c2784105 Content-Type: text/plain; charset=ISO-8859-1 Hi Haibin, Akbar, Good question and good discussion. Looking at the term agnostic, and looking at DECADE in a "layered" architecture setting, I would imagine that DECADE (or a general network storage layer, but I use DECADE as the Term) is at a base layer, and multiple Apps on top of it. Here by agnostic, we may mean DECADE supports the intersection or the union of the features required by the Apps. Clearly we may need to consider end-to-end arguements. A general storage system and a multimedia storage system may have different requirements. For multimedia, some QoS/DiffServ features may be essential. The workload (read, write) from different apps can be different, and hence one may optimize differently. The requirements on reliability (persistence) will also have impacts on the design. I feel that some precedng differences can be internal internal differences while others demand different APIs. A good discussion on this topic during rechartering will be very helpful indeed. Richard On Friday, June 15, 2012, Rahman, Akbar wrote: > Hi Haibin, > > > I agree that this is a very important question that you are asking. In > terms of an important use case, I think that we should consider if > DECADE can be applied to work as in-network storage as part of a cloud > computing environment. To me this would be the most "general > application agnostic content distribution platform inside the network" > that we could aim for. I remember that in some of the previous WG > discussions, we considered the possibility of supporting the cloud > computing model as part of the WG re-charter. I for one would vote in > favor of this. > > > > Akbar > > > > -----Original Message----- > From: decade-bounces@ietf.org [mailto: > decade-bounces@ietf.org ] On Behalf > Of Songhaibin > Sent: Thursday, June 14, 2012 2:43 AM > To: decade@ietf.org > Subject: [decade] Open discussion: Application agnostic content > distribution > > Hi guys, > > I think this is a very general and open question to all of the working > group. Which is also somewhat the high level goal of the working group. > In order to do a general application agnostic content distribution > platform inside the network, and the content distribution applications > will be likely to use it. what kind of functions and components it > should support? Or more general, what does the platform need? If you can > answer with use case, that would be good. The architecture document is a > good base. But I do not want the limit. > > BR, > -Haibin (as individual contributor) > --0015175ccf3e48f8c704c2784105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Haibin, Akbar,

Good question and good discussion. Loo= king at the term agnostic, and=A0
looking at DECADE in a "la= yered" architecture setting, I would imagine that
DECADE (or a ge= neral network storage layer, but I use DECADE as the
Term) is at a base layer, and multiple=A0Apps on top of it. Here by agnostic,=A0
we may mean DECADE supports the intersection or= the union of the
features required by the Apps. = Clearly we may need to consider end-to-end
arguements. A general storage system=A0and a multimedia storage system may
=A0have different requirements.= For=A0multimedia, some QoS/D= iffServ features=A0
may be essential. The workload (read, write) from different apps can be di= fferent,
and hence one may optimize diff= erently. The requirements on reliability (persistence)
will also have impacts on the design. I= feel that some precedng differences can be=A0
internal internal differences w= hile others demand different APIs. A good discussion
on this topic during rechartering will be= very helpful indeed.

Richard=A0

On Frida= y, June 15, 2012, Rahman, Akbar wrote:
Hi Haibin,


I agree that this is a very important question that you are asking. =A0In terms of an important use case, I think that we should consider if
DECADE can be applied to work as in-network storage as part of a cloud
computing environment. =A0To me this would be the most "general
application agnostic content distribution platform inside the network"=
that we could aim for. =A0I remember that in some of the previous WG
discussions, we considered the possibility of supporting the cloud
computing model as part of the WG re-charter. =A0I for one would vote in favor of this.



Akbar



-----Original Message-----
From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf
Of Songhaibin
Sent: Thursday, June 14, 2012 2:43 AM
To: decade@ietf.org
Subject: [decade] Open discussion: Application agnostic content
distribution

Hi guys,

I think this is a very general and open question to all of the working
group. Which is also somewhat the high level goal of the working group.
In order to do a general application agnostic content distribution
platform inside the network, and the content distribution applications
will be likely to use it. what kind of functions and components it
should support? Or more general, what does the platform need? If you can answer with use case, that would be good. The architecture document is a good base. But I do not want the limit.

BR,
-Haibin (as individual contributor)
--0015175ccf3e48f8c704c2784105-- From haibin.song@huawei.com Mon Jun 18 04:04:28 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F4C21F84FF for ; Mon, 18 Jun 2012 04:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.766 X-Spam-Level: X-Spam-Status: No, score=-5.766 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPNq843q1r19 for ; Mon, 18 Jun 2012 04:04:26 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id BBEF421F84DE for ; Mon, 18 Jun 2012 04:04:26 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGZ96835; Mon, 18 Jun 2012 07:04:26 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 18 Jun 2012 04:04:20 -0700 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 18 Jun 2012 04:04:21 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.36]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.003; Mon, 18 Jun 2012 19:04:14 +0800 From: Songhaibin To: "Rahman, Akbar" Thread-Topic: [decade] Open discussion: Application agnostic content distribution Thread-Index: Ac1J+OyLi9294JYgSC2pI1YHMlXEcQAVsvtAALtr7LA= Date: Mon, 18 Jun 2012 11:04:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "decade@ietf.org" Subject: Re: [decade] Open discussion: Application agnostic content distribution X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2012 11:04:28 -0000 Hi Akbar, Thank you for the response. Cloud storage is an interesting topic. If the e= xisting goal of the WG is application agnostic data distribution, it is som= ewhat part like cloud storage. But if we go for cloud storage, does it mean= a cloud storage data protocol and a cloud storage management protocol? An= d what does a cloud storage data protocol need to support? Does it need to = support database operations? Our resource model in the current architecture= is about the resource allocation for data distribution, is it part of the = management protocol or data protocol? I'm still not sure what the resource model would like in detail, how to all= ocate the bandwidth, storage space, connections and etc. resources to users= and applications. I can image some different mechanisms. Maybe the service= provider can choose one mechanism or the combination of them. (1) If there are different subscription levels among users/applications, th= e service provider can allocate the relative amount of resources according = to the levels. This mechanism is simple to design and implement. (2) The service provider can assign different weight to different users/app= lications, but at the same time, the amount of resource to guarantee an app= lication normal performance should be the minimum value for that applicatio= n, this value can be indicated by user/application according to its context (3) A flexible resource allocation (pay as you consume, by this concept, it= also somewhat like a cloud storage or cloud distribution?). Assume a reaso= nable pricing mechanism is provided, the user can use as much idle resource= as it wants, the upper bound is based on the physical limit of the equipme= nts and the network, and the lower bound is based on the application perfor= mance, e.g. the provider can allocate as much bandwidth to a VoD user as it= can, but the minimum is to guarantee a fluent play according to the encodi= ng rate, and this can be indicated by the app software installed in the end= user's machine. The bandwidth or other resources allocation can be dynamic= ally, e.g. in the adaptive streaming scenario. =20 I also imagine that if a local data locker server/in-network storage server= cannot provide enough resources to its end users, its neighbor data locker= servers can be used. There is something like a central controller for the = request routing and resource reservation (for distribution) in certain scen= arios. BR, -Haibin (as individual contributor) > -----Original Message----- > From: Rahman, Akbar [mailto:Akbar.Rahman@InterDigital.com] > Sent: Friday, June 15, 2012 1:20 AM > To: Songhaibin > Cc: decade@ietf.org > Subject: RE: [decade] Open discussion: Application agnostic content distr= ibution >=20 > Hi Haibin, >=20 >=20 > I agree that this is a very important question that you are asking. In > terms of an important use case, I think that we should consider if > DECADE can be applied to work as in-network storage as part of a cloud > computing environment. To me this would be the most "general > application agnostic content distribution platform inside the network" > that we could aim for. I remember that in some of the previous WG > discussions, we considered the possibility of supporting the cloud > computing model as part of the WG re-charter. I for one would vote in > favor of this. >=20 >=20 >=20 > Akbar >=20 >=20 >=20 > -----Original Message----- > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf > Of Songhaibin > Sent: Thursday, June 14, 2012 2:43 AM > To: decade@ietf.org > Subject: [decade] Open discussion: Application agnostic content > distribution >=20 > Hi guys, >=20 > I think this is a very general and open question to all of the working > group. Which is also somewhat the high level goal of the working group. > In order to do a general application agnostic content distribution > platform inside the network, and the content distribution applications > will be likely to use it. what kind of functions and components it > should support? Or more general, what does the platform need? If you can > answer with use case, that would be good. The architecture document is a > good base. But I do not want the limit. >=20 > BR, > -Haibin (as individual contributor) From haibin.song@huawei.com Mon Jun 18 04:15:38 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2223C21F85BB for ; Mon, 18 Jun 2012 04:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.884 X-Spam-Level: X-Spam-Status: No, score=-5.884 tagged_above=-999 required=5 tests=[AWL=0.714, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5r+XMLU+e+Xq for ; Mon, 18 Jun 2012 04:15:37 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id EB0E921F85C7 for ; Mon, 18 Jun 2012 04:15:36 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGZ97407; Mon, 18 Jun 2012 07:15:36 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 18 Jun 2012 04:14:34 -0700 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 18 Jun 2012 04:14:35 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.36]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 18 Jun 2012 19:14:27 +0800 From: Songhaibin To: "Y. Richard Yang" , "Rahman, Akbar" Thread-Topic: [decade] Open discussion: Application agnostic content distribution Thread-Index: Ac1J+OyLi9294JYgSC2pI1YHMlXEcQAVsvtA///9NYD/+hfFsA== Date: Mon, 18 Jun 2012 11:14:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.73] Content-Type: multipart/alternative; boundary="_000_E33E01DFD5BEA24B9F3F18671078951F23AAAE9Eszxeml534mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "decade@ietf.org" Subject: Re: [decade] Open discussion: Application agnostic content distribution X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2012 11:15:38 -0000 --_000_E33E01DFD5BEA24B9F3F18671078951F23AAAE9Eszxeml534mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Richard, From: yang.r.yang@gmail.com [mailto:yang.r.yang@gmail.com] On Behalf Of Y. = Richard Yang Sent: Friday, June 15, 2012 8:54 AM To: Rahman, Akbar Cc: Songhaibin; decade@ietf.org Subject: Re: [decade] Open discussion: Application agnostic content distrib= ution Hi Haibin, Akbar, Good question and good discussion. Looking at the term agnostic, and looking at DECADE in a "layered" architecture setting, I would imagine that DECADE (or a general network storage layer, but I use DECADE as the Term) is at a base layer, and multiple Apps on top of it. Here by agnostic, we may mean DECADE supports the intersection or the union of the features required by the Apps. [Haibin] Yes. Clearly we may need to consider end-to-end arguements. A general storage system and a multimedia storage system may have different requirements. For multimedia, some QoS/DiffServ features may be essential. The workload (read, write) from different apps can be dif= ferent, and hence one may optimize differently. [Haibin] I agree. The requirements on reliability (persistence) will also have impacts on the design. I feel that some precedng differences= can be internal internal differences while others demand different APIs. A good di= scussion on this topic during rechartering will be very helpful indeed. [Haibin] So beyond the general requirements, do you think it is required to= classify the applications to different types, and the protocol design shou= ld meet the requirements to each type of apps in general? Or is there some = other way to do it? This could be a good method to go and review the work I= MO. BR, -Haibin (as individual contributor) Richard On Friday, June 15, 2012, Rahman, Akbar wrote: Hi Haibin, I agree that this is a very important question that you are asking. In terms of an important use case, I think that we should consider if DECADE can be applied to work as in-network storage as part of a cloud computing environment. To me this would be the most "general application agnostic content distribution platform inside the network" that we could aim for. I remember that in some of the previous WG discussions, we considered the possibility of supporting the cloud computing model as part of the WG re-charter. I for one would vote in favor of this. Akbar -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org= ] On Behalf Of Songhaibin Sent: Thursday, June 14, 2012 2:43 AM To: decade@ietf.org Subject: [decade] Open discussion: Application agnostic content distribution Hi guys, I think this is a very general and open question to all of the working group. Which is also somewhat the high level goal of the working group. In order to do a general application agnostic content distribution platform inside the network, and the content distribution applications will be likely to use it. what kind of functions and components it should support? Or more general, what does the platform need? If you can answer with use case, that would be good. The architecture document is a good base. But I do not want the limit. BR, -Haibin (as individual contributor) --_000_E33E01DFD5BEA24B9F3F18671078951F23AAAE9Eszxeml534mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Richard= ,

 = ;

 = ;

From: yang.r.yang@gmail.com [mailto:yang.r.yang@gmail.com] On Behalf Of Y. Richard Yang
Sent: Friday, June 15, 2012 8:54 AM
To: Rahman, Akbar
Cc: Songhaibin; decade@ietf.org
Subject: Re: [decade] Open discussion: Application agnostic content = distribution

 

Hi Haibin, Akbar,

 

Good question and good discussi= on. Looking at the term agnostic, and 

looking at DECADE in a "la= yered" architecture setting, I would imagine that

DECADE (or a general network st= orage layer, but I use DECADE as the

Term) is at a base layer, and m= ultiple Apps on top of it. Here by ag= nostic, 

we may mean DECADE supports the intersection or the union of the

features required by the Apps.

 

[Haibin] Yes.

 

Clearly we may need to consider end-to-end

arguements. A general storage system and a multimedia storage system= may

 have different requirements. For multimedia, some QoS/DiffServ= features 

may be essential. The workload (read, write) from different apps can be d= ifferent,

and hence one may optimize differently.

 

[Haibin] I agree.

 

The requirements on reliability (persistence)

will also have impacts on the design. I feel that some precedng differenc= es can be 

internal internal differences while others demand different APIs. A good = discussion

on this topic during rechartering will be very helpful indeed.=

 = ;

[Haibin] S= o beyond the general requirements, do you think it is required to classify = the applications to different types, and the protocol design should meet the requirements to each type of apps in general? Or is there = some other way to do it? This could be a good method to go and review the w= ork IMO.

 = ;

BR,

-Haibin (a= s individual contributor)

 = ;

 = ;

 

Richard 

 

On Friday, June 15, 2012, Rahma= n, Akbar wrote:

Hi Haibin,


I agree that this is a very important question that you are asking.  I= n
terms of an important use case, I think that we should consider if
DECADE can be applied to work as in-network storage as part of a cloud
computing environment.  To me this would be the most "general
application agnostic content distribution platform inside the network"=
that we could aim for.  I remember that in some of the previous WG
discussions, we considered the possibility of supporting the cloud
computing model as part of the WG re-charter.  I for one would vote in=
favor of this.



Akbar



-----Original Message-----
From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf
Of Songhaibin
Sent: Thursday, June 14, 2012 2:43 AM
To: decade@ietf.org
Subject: [decade] Open discussion: Application agnostic content
distribution

Hi guys,

I think this is a very general and open question to all of the working
group. Which is also somewhat the high level goal of the working group.
In order to do a general application agnostic content distribution
platform inside the network, and the content distribution applications
will be likely to use it. what kind of functions and components it
should support? Or more general, what does the platform need? If you can answer with use case, that would be good. The architecture document is a good base. But I do not want the limit.

BR,
-Haibin (as individual contributor)

--_000_E33E01DFD5BEA24B9F3F18671078951F23AAAE9Eszxeml534mbxchi_-- From heavyxue@gmail.com Mon Jun 18 13:12:23 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7B311E8088 for ; Mon, 18 Jun 2012 13:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0DbWr-ar6JF for ; Mon, 18 Jun 2012 13:12:22 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id BD60F11E80A5 for ; Mon, 18 Jun 2012 13:12:20 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so8728990pbc.31 for ; Mon, 18 Jun 2012 13:12:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LxFBusgtUWl8bCmrc7w+OF+Hh23OFrTgEqHRNDeW4+U=; b=XwQ1JY2ASvmWwnlqWaAyNgnqrsq8Tq54r+6EiNKVxyoEvowd/B5s+XyKywErRhJfIo y8OkxOLyF9QUi9ZFOxOkH7e7ww7Lo/nrCNzReT/xSV+m/uEM3vcl0sYTA/W60buxPq2A beMxb4cAwGX/1uA1MCUYjNOc/GYw7Xi6mgl2cEby8m0Q+Z4jyJbdjm6o3pWVQ7DeLfKI tcqBHJ+QhHdh/WgbE21NP7CCcODtUiq51+GXZAyUKwx0HxRGsmCAeYqX90BjHZulHzby XrM3TwkVUpr1kK/2op3+9qorhkHUCl5akcVcO+c+/YSoc8/MZ50Y+2OSDq9W51td7oyu pDEw== Received: by 10.68.222.197 with SMTP id qo5mr44375279pbc.72.1340050340461; Mon, 18 Jun 2012 13:12:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.232.7 with HTTP; Mon, 18 Jun 2012 13:11:50 -0700 (PDT) In-Reply-To: References: From: Haiwei Xue Date: Mon, 18 Jun 2012 16:11:50 -0400 Message-ID: To: Songhaibin Content-Type: multipart/alternative; boundary=047d7b2ee03f863dde04c2c4c80e Cc: "decade@ietf.org" Subject: Re: [decade] Open discussion: Application agnostic content distribution X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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, 18 Jun 2012 20:12:23 -0000 --047d7b2ee03f863dde04c2c4c80e Content-Type: text/plain; charset=ISO-8859-1 Hi Haibin, I am confused, who dose 'application agnostic content distribution platform' face with? what kinds of applications do mean by 'content distribution applications will be likely to use it'. Do you mean content provider? It my understanding that 'application agnostic content distribution platform' is doing something CDN do. So what is new for 'application agnostic content distribution platform', who will benefit from it? Thanks. Haiwei On Thu, Jun 14, 2012 at 2:42 AM, Songhaibin wrote: > Hi guys, > > I think this is a very general and open question to all of the working > group. Which is also somewhat the high level goal of the working group. In > order to do a general application agnostic content distribution platform > inside the network, and the content distribution applications will be > likely to use it. what kind of functions and components it should support? Or more general, > what does the platform need? If you can answer with use case, that would be > good. The architecture document is a good base. But I do not want the limit. > > BR, > -Haibin (as individual contributor) > --047d7b2ee03f863dde04c2c4c80e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Haibin,

I am confused, who dose 'appl= ication agnostic content distribution platform' face with?=A0wha= t kinds of applications do mean by 'content distribution applications w= ill be likely to use it'. Do you mean content provider?

It my understanding that 'application a= gnostic content distribution platform' is doing something CDN do= . So=A0what is new for 'application agnostic content distri= bution platform', who will benefit from it?

Thanks.

Haiwei

On Thu, Jun 14, 2012 at 2:42 AM, Songhaibin <haibi= n.song@huawei.com> wrote:
Hi guys,

I think this is a very general and open question to all of the working grou= p. Which is also somewhat the high level goal of the working group. In orde= r to do a general application agnostic content distribution platform inside= the network, and the content distribution applications will be likely to u= se it.
what kind of functions and components it sh= ould support? Or more general, what does the platform need? If you can answ= er with use case, that would be good. The architecture document is a good b= ase. But I do not want the limit.

BR,
-Haibin (as individual contributor)

--047d7b2ee03f863dde04c2c4c80e-- From haibin.song@huawei.com Tue Jun 19 01:53:10 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3021421F85BD for ; Tue, 19 Jun 2012 01:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.96 X-Spam-Level: X-Spam-Status: No, score=-5.96 tagged_above=-999 required=5 tests=[AWL=0.638, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aoxzqqoa+Ork for ; Tue, 19 Jun 2012 01:53:09 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 33E3821F859E for ; Tue, 19 Jun 2012 01:53:09 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHH97718; Tue, 19 Jun 2012 04:53:09 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 19 Jun 2012 01:52:07 -0700 Received: from SZXEML435-HUB.china.huawei.com (10.72.61.63) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 19 Jun 2012 01:52:09 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.36]) by szxeml435-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Tue, 19 Jun 2012 16:52:05 +0800 From: Songhaibin To: Haiwei Xue Thread-Topic: [decade] Open discussion: Application agnostic content distribution Thread-Index: Ac1J+OyLi9294JYgSC2pI1YHMlXEcQDUp2kAACrtEIA= Date: Tue, 19 Jun 2012 08:52:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.73] Content-Type: multipart/alternative; boundary="_000_E33E01DFD5BEA24B9F3F18671078951F23AB094Bszxeml534mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "decade@ietf.org" Subject: Re: [decade] Open discussion: Application agnostic content distribution X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2012 08:53:10 -0000 --_000_E33E01DFD5BEA24B9F3F18671078951F23AB094Bszxeml534mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Haiwei, Thank you for your questions. From: Haiwei Xue [mailto:heavyxue@gmail.com] Sent: Tuesday, June 19, 2012 4:12 AM To: Songhaibin Cc: decade@ietf.org Subject: Re: [decade] Open discussion: Application agnostic content distrib= ution Hi Haibin, I am confused, who dose 'application agnostic content distribution platform= ' face with? what kinds of applications do mean by 'content distribution ap= plications will be likely to use it'. Do you mean content provider? [Haibin] Content providers can be the users. Besides that, applications tha= t do content distribution work can also be the users. It my understanding that 'application agnostic content distribution platfor= m' is doing something CDN do. So what is new for 'application agnostic cont= ent distribution platform', who will benefit from it? [Haibin] The content distribution applications can benefit from an open dis= tribution paradigm that is easy to use, easy to migrate, and easy to integr= ate their own distribution polices. The platform service providers will als= o benefit with open connectivity to other service providers and easy mainte= nance. Any thoughts? BR, -Haibin Thanks. Haiwei On Thu, Jun 14, 2012 at 2:42 AM, Songhaibin > wrote: Hi guys, I think this is a very general and open question to all of the working grou= p. Which is also somewhat the high level goal of the working group. In orde= r to do a general application agnostic content distribution platform inside= the network, and the content distribution applications will be likely to u= se it. what kind of functions and components it should support? Or more general, w= hat does the platform need? If you can answer with use case, that would be = good. The architecture document is a good base. But I do not want the limit= . BR, -Haibin (as individual contributor) --_000_E33E01DFD5BEA24B9F3F18671078951F23AB094Bszxeml534mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Haiwei,=

 = ;

Thank you = for your questions.

 = ;

From: Haiwei Xue [mailto:heavyxue@gmail.com]
Sent: Tuesday, June 19, 2012 4:12 AM
To: Songhaibin
Cc: decade@ietf.org
Subject: Re: [decade] Open discussion: Application agnostic content = distribution

 

Hi Haibin,

 

I am confused, who dose 'applic= ation agnostic content distribution platform' face with? what kinds of= applications do mean by 'content distribution applications will be likely = to use it'. Do you mean content provider?

&n= bsp;

[Haibin] C= ontent providers can be the users. Besides that, applications that do conte= nt distribution work can also be the users.

 = ;

It my understanding that 'appli= cation agnostic content distribution platform' is doing something CDN do. S= o what is new for 'application agnostic content distribution platform'= , who will benefit from it?

&n= bsp;

[Haibin] T= he content distribution applications can benefit from an open distribution = paradigm that is easy to use, easy to migrate, and easy to integrate their own distribution polices. The platform service providers w= ill also benefit with open connectivity to other service providers and easy= maintenance.

 = ;

Any though= ts?

 = ;

BR,

-Haibin

 = ;

 = ;

 = ;

Thanks.

 

= Haiwei

On Thu, Jun 14, 2012 at 2:42 AM= , Songhaibin <haibin.song@huawei.com> wrote:

Hi guys,

I think this is a very general and open question to all of the working grou= p. Which is also somewhat the high level goal of the working group. In orde= r to do a general application agnostic content distribution platform inside= the network, and the content distribution applications will be likely to use it.

what kind of functions and comp= onents it should support? Or more general, what does the platform need? If = you can answer with use case, that would be good. The architecture document= is a good base. But I do not want the limit.

BR,
-Haibin (as individual contributor)

 

--_000_E33E01DFD5BEA24B9F3F18671078951F23AB094Bszxeml534mbxchi_-- From heavyxue@gmail.com Tue Jun 19 07:50:11 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E3721F860F for ; Tue, 19 Jun 2012 07:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtBkFeBO8pfo for ; Tue, 19 Jun 2012 07:50:09 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECEC21F85FC for ; Tue, 19 Jun 2012 07:50:09 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so9882817pbc.31 for ; Tue, 19 Jun 2012 07:50:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GZvFLZfmguxqUf/zKJ1Uo4lxBGixN9JhEye/k9gjvcs=; b=iOUmWpMWPIdEYosGQjR8n5mCASlR2vu+xeELAJ1ubu8vn4BrvZchxDh3bh9w4XmZse ZF28773hUReUPhdZI6uIvoIks8k+1tSFAAinHe/b6GiwJgCLOeSGUibI6rNsYnenAAZL XvFD+rMKSm60rQ/kQkTsLK0QPvFkqbvlfKyl7kQ1aOW1q/6ttla4yiSPbfJC6RFukqC1 Tz/XUXvnz3DpetkbD86sPwQqDMMsAfgM6qjohigB5BW0lcZfkZk3IJ4IpfYG9R+S1c7w SiTPnO/uFuYsy21uadLy7CsgNkp6o69aGx8zTQ+mGXeP+fX5TOckW6IEKhTXo9uVEpb4 lFeg== Received: by 10.68.223.198 with SMTP id qw6mr48384078pbc.94.1340117408788; Tue, 19 Jun 2012 07:50:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.232.7 with HTTP; Tue, 19 Jun 2012 07:49:38 -0700 (PDT) In-Reply-To: References: From: Haiwei Xue Date: Tue, 19 Jun 2012 10:49:38 -0400 Message-ID: To: Songhaibin Content-Type: multipart/alternative; boundary=047d7b1601b91bb25d04c2d466aa Cc: "decade@ietf.org" Subject: Re: [decade] Open discussion: Application agnostic content distribution X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 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, 19 Jun 2012 14:50:12 -0000 --047d7b1601b91bb25d04c2d466aa Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Haibin Thank you for your reply. While, I am not convinced: On Tue, Jun 19, 2012 at 4:52 AM, Songhaibin wrote: > Hi Haiwei,**** > > ** ** > > Thank you for your questions.**** > > ** ** > > *From:* Haiwei Xue [mailto:heavyxue@gmail.com] > *Sent:* Tuesday, June 19, 2012 4:12 AM > *To:* Songhaibin > *Cc:* decade@ietf.org > > *Subject:* Re: [decade] Open discussion: Application agnostic content > distribution**** > > ** ** > > Hi Haibin,**** > > ** ** > > I am confused, who dose 'application agnostic content distribution > platform' face with? what kinds of applications do mean by 'content > distribution applications will be likely to use it'. Do you mean content > provider?**** > > ** ** > > [Haibin] Content providers can be the users. Besides that, applications > that do content distribution work can also be the users.**** > > ** ** > > It my understanding that 'application agnostic content distribution > platform' is doing something CDN do. So what is new for 'application > agnostic content distribution platform', who will benefit from it?**** > > ** ** > > [Haibin] The content distribution applications can benefit from an open > distribution paradigm that is easy to use, easy to migrate, and easy to > integrate their own distribution polices. > [Haiwei] Q1: If content distribution application integrated their own distribution polices, then they need to aware that is such a supported platform, so would the term 'application agnostic' make sense? [Haiwei] Q2: What do you mean by 'distribution polices', content distribution algorithms? or what? If it is algorithms, then simple API is not enough since these algorithms could be very complex, which means that the platform need to run applications=91 program. Then we need talk about more on the cloud computing. > The platform service providers will also benefit with open connectivity t= o > other service providers and easy maintenance.**** > > ** ** > > Any thoughts? > [Haiwei] Q3: I still did not see the benefit of this platform, For content provider using this platform is no difference with CDN; For content applications, Can you show me a example/usecase of such a application that it need to deploy their own distribution polices? Thanks. Haiwei > **** > > ** ** > > BR,**** > > -Haibin**** > > ** ** > > ** ** > > ** ** > > Thanks.**** > > ** ** > > Haiwei**** > > On Thu, Jun 14, 2012 at 2:42 AM, Songhaibin > wrote:**** > > Hi guys, > > I think this is a very general and open question to all of the working > group. Which is also somewhat the high level goal of the working group. I= n > order to do a general application agnostic content distribution platform > inside the network, and the content distribution applications will be > likely to use it.**** > > what kind of functions and components it should support? Or more general, > what does the platform need? If you can answer with use case, that would = be > good. The architecture document is a good base. But I do not want the lim= it. > > BR, > -Haibin (as individual contributor)**** > > ** ** > --047d7b1601b91bb25d04c2d466aa Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Haibin

Thank you for your reply. While,=A0I am not co= nvinced:

On Tue, Jun 19= , 2012 at 4:52 AM, Songhaibin <haibin.song@huawei.com> = wrote:

Hi Haiwei,=

=A0=

Thank you = for your questions.

=A0=

From: Haiwei Xue [mailto:heavyxue@gmail.com]
Sent: Tuesday, June 19, 2012 4:12 AM
To: Songhaibin
Cc: decade@ietf= .org


Subject: Re: [decade] Open discussion: Application agnostic content = distribution

=A0

Hi Haibin,=

=A0

I am confused, who dose 'ap= plication agnostic content distribution platform' face with?=A0what kin= ds of applications do mean by 'content distribution applications will b= e likely to use it'. Do you mean content provider?=

= =A0

[Haibin] C= ontent providers can be the users. Besides that, applications that do conte= nt distribution work can also be the users.

=A0=

It my understanding that 'a= pplication agnostic content distribution platform' is doing something C= DN do. So=A0what is new for 'application agnostic content distribution = platform', who will benefit from it?

= =A0

[Haibin] T= he content distribution applications can benefit from an open distribution = paradigm that is easy to use,=A0easy to mig= rate, and easy to integrate their own distribution polices.=A0

<= /div>

=A0 =A0 =A0[Haiwei] Q1: If content di= stribution application=A0integrated=A0their own distribution polices, then = they need to aware that is such a supported platform, so would the term = 9;application agnostic' make sense?

=A0 =A0 =A0[Haiwei] Q2: What do you mean by 'distribution polices', content distribution algorithms? or wha= t? =A0If it is algorithms, then simple API is not enough since these algori= thms could be very complex, which means that the platform need to run appli= cations=91 program. Then we need talk about more on the cloud computing.
=A0

The p= latform service providers will also benefit with open connectivity to other= service providers and easy maintenance.

=A0=

Any though= ts?


=A0 = =A0[Haiwei] Q3: I still did not see the benefit of this platform, For conte= nt provider using this platform is no difference with CDN; For content appl= ications, Can you show me a example/usecase of such a application that it n= eed to deploy their own=A0=A0distribution polices?

Thanks.

Haiwei

<= /div>
=A0

=A0=

BR,=

-Haibin=

=A0=

=A0=

=A0=

Thanks.

=A0

= Haiwei

On Thu, Jun 14, 2012 at 2:42 AM= , Songhaibin <haibin.song@huawei.com> wrote:

Hi guys,

I think this is a very general and open question to all of the working grou= p. Which is also somewhat the high level goal of the working group. In orde= r to do a general application agnostic content distribution platform inside= the network, and the content distribution applications will be likely to use it.

what kind of functions and comp= onents it should support? Or more general, what does the platform need? If = you can answer with use case, that would be good. The architecture document= is a good base. But I do not want the limit.

BR,
-Haibin (as individual contributor)

=A0


--047d7b1601b91bb25d04c2d466aa-- From zongning@huawei.com Tue Jun 19 17:35:15 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA75A11E8128 for ; Tue, 19 Jun 2012 17:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.099 X-Spam-Level: X-Spam-Status: No, score=-104.099 tagged_above=-999 required=5 tests=[AWL=2.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XL1plLrEk4N7 for ; Tue, 19 Jun 2012 17:35:12 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7C08F11E80D5 for ; Tue, 19 Jun 2012 17:35:12 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHB17229; Tue, 19 Jun 2012 20:35:11 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 19 Jun 2012 17:34:00 -0700 Received: from SZXEML428-HUB.china.huawei.com (10.72.61.36) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 19 Jun 2012 17:33:58 -0700 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.70]) by szxeml428-hub.china.huawei.com ([10.72.61.36]) with mapi id 14.01.0323.003; Wed, 20 Jun 2012 08:33:50 +0800 From: Zongning To: Haiwei Xue , Songhaibin Thread-Topic: [decade] Open discussion: Application agnostic content distribution Thread-Index: AQHNTiq/phZkBLdD30uYK3vF4dGaM5cCU/rQ Date: Wed, 20 Jun 2012 00:33:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.35] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC66677924A84695szxeml504mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "decade@ietf.org" Subject: Re: [decade] Open discussion: Application agnostic content distribution X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 00:35:16 -0000 --_000_B0D29E0424F2DE47A0B36779EC66677924A84695szxeml504mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Haiwei, Thank you for the questions. See my thoughts inline. From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of= Haiwei Xue Sent: Tuesday, June 19, 2012 10:50 PM To: Songhaibin Cc: decade@ietf.org Subject: Re: [decade] Open discussion: Application agnostic content distrib= ution Hi Haibin Thank you for your reply. While, I am not convinced: On Tue, Jun 19, 2012 at 4:52 AM, Songhaibin > wrote: Hi Haiwei, Thank you for your questions. From: Haiwei Xue [mailto:heavyxue@gmail.com] Sent: Tuesday, June 19, 2012 4:12 AM To: Songhaibin Cc: decade@ietf.org Subject: Re: [decade] Open discussion: Application agnostic content distrib= ution Hi Haibin, I am confused, who dose 'application agnostic content distribution platform= ' face with? what kinds of applications do mean by 'content distribution ap= plications will be likely to use it'. Do you mean content provider? [Haibin] Content providers can be the users. Besides that, applications tha= t do content distribution work can also be the users. It my understanding that 'application agnostic content distribution platfor= m' is doing something CDN do. So what is new for 'application agnostic cont= ent distribution platform', who will benefit from it? [Haibin] The content distribution applications can benefit from an open dis= tribution paradigm that is easy to use, easy to migrate, and easy to integr= ate their own distribution polices. [Haiwei] Q1: If content distribution application integrated their own = distribution polices, then they need to aware that is such a supported plat= form, so would the term 'application agnostic' make sense? [Ning] A1: I think Haibin meant that the content distribution platform shou= ld provide general APIs to applications to satisfy content distribution pol= icies such as resource allocation (e.g. bandwidth restriction, how many and= when to put data copies) for each content distribution instance. Please re= fer to DECADE drafts on survey and problem statement. [Haiwei] Q2: What do you mean by 'distribution polices', content distr= ibution algorithms? or what? If it is algorithms, then simple API is not e= nough since these algorithms could be very complex, which means that the pl= atform need to run applications' program. Then we need talk about more on t= he cloud computing. [Ning] A2: I think the content distribution platform will have a clear dema= rcation with application regarding the distribution policies. The platform = will focus on how to efficiently delivery the data in terms of the delivery= efficiency, network efficiency. The application will care about the high l= evel flow possibly integrated with business concerns and the properties of = the content, e.g. how many sources of the data, where to put the data, etc. The platform service providers will also benefit with open connectivity to = other service providers and easy maintenance. Any thoughts? [Haiwei] Q3: I still did not see the benefit of this platform, For conte= nt provider using this platform is no difference with CDN; For content appl= ications, Can you show me a example/usecase of such a application that it n= eed to deploy their own distribution polices? [Ning]: A3: For design point of view, an open content distribution platform= with general APIs to applications will always give applications more flexi= ble and on-demand capabilities on content distribution. I am not a right pe= rson to give you a good example for CP/SP at this moment, but I really beli= eve this is a good point we need to discuss and confirm with CP/SPs. Thanks. Haiwei BR, -Haibin Thanks. Haiwei On Thu, Jun 14, 2012 at 2:42 AM, Songhaibin > wrote: Hi guys, I think this is a very general and open question to all of the working grou= p. Which is also somewhat the high level goal of the working group. In orde= r to do a general application agnostic content distribution platform inside= the network, and the content distribution applications will be likely to u= se it. what kind of functions and components it should support? Or more general, w= hat does the platform need? If you can answer with use case, that would be = good. The architecture document is a good base. But I do not want the limit= . BR, -Haibin (as individual contributor) --_000_B0D29E0424F2DE47A0B36779EC66677924A84695szxeml504mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Haiwei= ,

 = ;

Thank you = for the questions. See my thoughts inline.

 = ;

From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.o= rg] On Behalf Of Haiwei Xue
Sent: Tuesday, June 19, 2012 10:50 PM
To: Songhaibin
Cc: decade@ietf.org
Subject: Re: [decade] Open discussion: Application agnostic content = distribution

 

Hi Haibin

 

Thank you for your reply. While= , I am not convinced:

 

On Tue, Jun 19, 2012 at 4:52 AM= , Songhaibin <haibin.song@huawei.com> wrote:

Hi Haiwei,

 

Thank you for your quest= ions.

 

From: Haiwei Xue [mailto:heavyx= ue@gmail.com]
Sent: Tuesday, June 19, 2012 4:12 AM
To: Songhaibin
Cc: decade@ietf= .org


Subject: Re: [decade] Open discussion: Application agnostic content = distribution

 

Hi Haibin,

 

I am confused, who dose 'application agnostic= content distribution platform' face with? what kinds of applications = do mean by 'content distribution applications will be likely to use it'. Do you mean content provider?=

 

[Haibin] Content provide= rs can be the users. Besides that, applications that do content distribution work can also be the users.<= /o:p>

 

It my understanding that 'application agnosti= c content distribution platform' is doing something CDN do. So what is= new for 'application agnostic content distribution platform', who will benefit from it?

 

[Haibin] The content dis= tribution applications can benefit from an open distribution paradigm that is easy to use, easy to migrate, and easy to integrate = their own distribution polices. 

 

     [Haiwei] Q1= : If content distribution application integrated their own distri= bution polices, then they need to aware that is such a supported platform, = so would the term 'application agnostic' make sense?

 = ;

[Ning] A1:= I think Haibin meant that the content distribution platform should provide= general APIs to applications to satisfy content distribution policies such as resource allocation (e.g. bandwidth restriction, how many= and when to put data copies) for each content distribution instance. Pleas= e refer to DECADE drafts on survey and problem statement.=

 = ;

     [Haiwei] Q2= : What do you mean by 'dis= tribution polices', content distribution algori= thms? or what?  If it is algorithms, then simple API is not enough since th= ese algorithms could be very complex, which means that the platform need to= run applications‘ program. Then we need talk about more on the cloud= computing.

 = ;

[Ning] A2:= I think the content distribution platform will have a clear demarcation wi= th application regarding the distribution policies. The platform will focus on how to efficiently delivery the data in terms of the deliver= y efficiency, network efficiency. The application will care about the high = level flow possibly integrated with business concerns and the properties of= the content, e.g. how many sources of the data, where to put the data, etc.

 

The platform service pro= viders will also benefit with open connectivity to other service providers and easy maintenance.

 

Any thoughts?

 

   [Haiwei] Q3: I sti= ll did not see the benefit of this platform, For content provider using thi= s platform is no difference with CDN; For content applications, Can you sho= w me a example/usecase of such a application that it need to deploy their own  distribution polices?

 = ;

[Ning]: A3= : For design point of view, an open content distribution platform with gene= ral APIs to applications will always give applications more flexible and on-demand capabilities on content distribution. I am not a ri= ght person to give you a good example for CP/SP at this moment, but I reall= y believe this is a good point we need to discuss and confirm with CP/SPs.<= o:p>

 

Thanks.

 

Haiwei

 

 

 

BR,

-Haibin

 

 

 

Thanks.

 

Haiwei

On Thu, Jun 14, 2012 at 2:42 AM, Songhaibin &= lt;haibin.song@= huawei.com> wrote:

Hi guys,

I think this is a very general and open question to all of the working grou= p. Which is also somewhat the high level goal of the working group. In orde= r to do a general application agnostic content distribution platform inside= the network, and the content distribution applications will be likely to use it.

what kind of functions and components it shou= ld support? Or more general, what does the platform need? If you can answer= with use case, that would be good. The architecture document is a good base. But I do not want the limit.

BR,
-Haibin (as individual contributor)

 

 

--_000_B0D29E0424F2DE47A0B36779EC66677924A84695szxeml504mbschi_-- From haibin.song@huawei.com Wed Jun 20 19:07:44 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E0E21F858F for ; Wed, 20 Jun 2012 19:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.024 X-Spam-Level: X-Spam-Status: No, score=-6.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRMuZhYnk3zN for ; Wed, 20 Jun 2012 19:07:44 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9618521F8597 for ; Wed, 20 Jun 2012 19:07:43 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHJ26962; Wed, 20 Jun 2012 22:07:43 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 20 Jun 2012 19:06:08 -0700 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 20 Jun 2012 19:06:13 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.36]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.003; Thu, 21 Jun 2012 10:06:09 +0800 From: Songhaibin To: "decade@ietf.org" Thread-Topic: Working Group Last Call: draft-ietf-decade-arch-07 Thread-Index: Ac1PUmra8pF/55OcSfCOdrGa28N+Sw== Date: Thu, 21 Jun 2012 02:06:07 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [decade] Working Group Last Call: draft-ietf-decade-arch-07 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 02:07:44 -0000 Dear folks, After the first round of the last call, the architecture document has many = changes to resolve comments from reviewers as well as area director and exp= erts from other areas. Thanks to the reviewers and the authors. So Rich and I now start another round of WGLC on draft-ietf-decade-arch-07,= ending Friday, July 6th. Please review the document and reply with your co= mments. Thanks, -Haibin and Rich (co-chairs) From internet-drafts@ietf.org Wed Jun 20 20:13:34 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F35611E80BD; Wed, 20 Jun 2012 20:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.501 X-Spam-Level: X-Spam-Status: No, score=-102.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOC3R3MpxcUa; Wed, 20 Jun 2012 20:13:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90EE211E8073; Wed, 20 Jun 2012 20:13:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120621031333.24814.83113.idtracker@ietfa.amsl.com> Date: Wed, 20 Jun 2012 20:13:33 -0700 Cc: decade@ietf.org Subject: [decade] I-D Action: draft-ietf-decade-integration-example-04.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 03:13:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Decoupled Application Data Enroute Workin= g Group of the IETF. Title : Integration Examples of DECADE System Author(s) : Ning Zong Xiaohui Chen Zhigang Huang Lijiang Chen Hongqiang Liu Filename : draft-ietf-decade-integration-example-04.txt Pages : 23 Date : 2012-06-20 Abstract: Decoupled Application Data Enroute (DECADE) system is an in-network storage infrastructure which is still under discussion in IETF. This document presents two detailed examples of how to integrate such in- network storage infrastructure into peer-to-peer (P2P) applications to achieve more efficient content distribution, and Application Layer Traffic Optimization (ALTO) system to build a content distribution platform for Content Providers (CPs). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-decade-integration-example There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-decade-integration-example-04 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-decade-integration-example-= 04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From zongning@huawei.com Wed Jun 20 20:18:25 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4110611E8079 for ; Wed, 20 Jun 2012 20:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.724 X-Spam-Level: X-Spam-Status: No, score=-104.724 tagged_above=-999 required=5 tests=[AWL=1.875, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id us2SBKn3eAog for ; Wed, 20 Jun 2012 20:18:24 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A377711E8073 for ; Wed, 20 Jun 2012 20:18:24 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHJ30336; Wed, 20 Jun 2012 23:18:24 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 20 Jun 2012 20:18:25 -0700 Received: from SZXEML428-HUB.china.huawei.com (10.72.61.36) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 20 Jun 2012 20:18:23 -0700 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.70]) by szxeml428-hub.china.huawei.com ([10.72.61.36]) with mapi id 14.01.0323.003; Thu, 21 Jun 2012 11:18:18 +0800 From: Zongning To: "decade@ietf.org" Thread-Topic: [decade] I-D Action: draft-ietf-decade-integration-example-04.txt Thread-Index: AQHNT1vbAmbcLk6JaE23lF53G8jmKpcEGYTg Date: Thu, 21 Jun 2012 03:18:17 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.35] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [decade] FW: I-D Action: draft-ietf-decade-integration-example-04.txt X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 03:18:25 -0000 SGksIEZvbGtzLA0KDQpQbGVhc2Ugc2VlIHRoZSBuZXcgcmV2aXNpb24gb2YgREVDQURFIGludGVn cmF0aW9uIGV4YW1wbGVzIGRyYWZ0Lg0KVGhhbmtzIHRvIFJpY2guIEFsaW1pLCBBa2JhciwgSGFp YmluIGZvciB5b3VyIHZhbHVhYmxlIGNvbW1lbnRzLiBQbGVhc2UgbGV0IG1lIGtub3cgaWYgYW55 IGNvbW1lbnRzIGFyZSBzdGlsbCBub3QgYWRkcmVzc2VkIGluIHRoZSBuZXcgcmV2aXNpb24uDQoN Ci1OaW5nDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZGVjYWRlLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkZWNhZGUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm DQo+IE9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPiBTZW50OiBUaHVyc2RheSwgSnVuZSAy MSwgMjAxMiAxMToxNCBBTQ0KPiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQo+IENjOiBkZWNh ZGVAaWV0Zi5vcmcNCj4gU3ViamVjdDogW2RlY2FkZV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1k ZWNhZGUtaW50ZWdyYXRpb24tZXhhbXBsZS0wNC50eHQNCj4gDQo+IA0KPiBBIE5ldyBJbnRlcm5l dC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGly ZWN0b3JpZXMuDQo+ICBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBEZWNvdXBsZWQg QXBwbGljYXRpb24gRGF0YSBFbnJvdXRlIFdvcmtpbmcNCj4gR3JvdXAgb2YgdGhlIElFVEYuDQo+ IA0KPiAJVGl0bGUgICAgICAgICAgIDogSW50ZWdyYXRpb24gRXhhbXBsZXMgb2YgREVDQURFIFN5 c3RlbQ0KPiAJQXV0aG9yKHMpICAgICAgIDogTmluZyBab25nDQo+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgWGlhb2h1aSBDaGVuDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgWmhpZ2Fu ZyBIdWFuZw0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIExpamlhbmcgQ2hlbg0KPiAgICAg ICAgICAgICAgICAgICAgICAgICAgIEhvbmdxaWFuZyBMaXUNCj4gCUZpbGVuYW1lICAgICAgICA6 IGRyYWZ0LWlldGYtZGVjYWRlLWludGVncmF0aW9uLWV4YW1wbGUtMDQudHh0DQo+IAlQYWdlcyAg ICAgICAgICAgOiAyMw0KPiAJRGF0ZSAgICAgICAgICAgIDogMjAxMi0wNi0yMA0KPiANCj4gQWJz dHJhY3Q6DQo+ICAgIERlY291cGxlZCBBcHBsaWNhdGlvbiBEYXRhIEVucm91dGUgKERFQ0FERSkg c3lzdGVtIGlzIGFuIGluLW5ldHdvcmsNCj4gICAgc3RvcmFnZSBpbmZyYXN0cnVjdHVyZSB3aGlj aCBpcyBzdGlsbCB1bmRlciBkaXNjdXNzaW9uIGluIElFVEYuICBUaGlzDQo+ICAgIGRvY3VtZW50 IHByZXNlbnRzIHR3byBkZXRhaWxlZCBleGFtcGxlcyBvZiBob3cgdG8gaW50ZWdyYXRlIHN1Y2gg aW4tDQo+ICAgIG5ldHdvcmsgc3RvcmFnZSBpbmZyYXN0cnVjdHVyZSBpbnRvIHBlZXItdG8tcGVl ciAoUDJQKSBhcHBsaWNhdGlvbnMNCj4gICAgdG8gYWNoaWV2ZSBtb3JlIGVmZmljaWVudCBjb250 ZW50IGRpc3RyaWJ1dGlvbiwgYW5kIEFwcGxpY2F0aW9uIExheWVyDQo+ICAgIFRyYWZmaWMgT3B0 aW1pemF0aW9uIChBTFRPKSBzeXN0ZW0gdG8gYnVpbGQgYSBjb250ZW50IGRpc3RyaWJ1dGlvbg0K PiAgICBwbGF0Zm9ybSBmb3IgQ29udGVudCBQcm92aWRlcnMgKENQcykuDQo+IA0KPiANCj4gVGhl IElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZGVjYWRlLWludGVncmF0aW9u LWV4YW1wbGUNCj4gDQo+IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxl IGF0Og0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRlY2FkZS1pbnRl Z3JhdGlvbi1leGFtcGxlLTA0DQo+IA0KPiBBIGRpZmYgZnJvbSBwcmV2aW91cyB2ZXJzaW9uIGlz IGF2YWlsYWJsZSBhdDoNCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1pZXRmLWRlY2FkZS1pbnRlZ3JhdGlvbi1leGFtcGxlLTA0DQo+IA0KPiANCj4gSW50ZXJuZXQt RHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiBmdHA6Ly9m dHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQo= From yry@cs.yale.edu Sat Jun 30 03:40:57 2012 Return-Path: X-Original-To: decade@ietfa.amsl.com Delivered-To: decade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1671F21F85A0 for ; Sat, 30 Jun 2012 03:40:57 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9YBo5I22dPV for ; Sat, 30 Jun 2012 03:40:56 -0700 (PDT) Received: from vm-emlprdomr-03.its.yale.edu (vm-emlprdomr-03.its.yale.edu [130.132.50.144]) by ietfa.amsl.com (Postfix) with ESMTP id 1D89521F8599 for ; Sat, 30 Jun 2012 03:40:52 -0700 (PDT) Received: from [192.168.1.108] ([221.221.17.127]) (authenticated bits=0) by vm-emlprdomr-03.its.yale.edu (8.14.4/8.14.4) with ESMTP id q5UAeSOG009725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 30 Jun 2012 06:40:48 -0400 Message-ID: <4FEED79A.1090906@cs.yale.edu> Date: Sat, 30 Jun 2012 18:40:26 +0800 From: "Y. Richard Yang" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "DECADE@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on 130.132.50.144 Subject: [decade] -req and -arch documents X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 10:40:57 -0000 Dear DECADE participants, Both -req and -arch documents have received extensive, excellent reviews. In the process of revising the documents and looking at the two documents, we have some questions to seek input from the participants: Q1. Both -req and -arch define some terms, including DECADE-compatible client, DECADE-compatible server, etc. This appears to be redundant. Should such terms be defined in -req or -arch? The current thinking is -req. Any comments? Q2. There are multiple paragraphs defining requirements in -arch, e.g., Sec. 4.4 on naming. Should these be moved to -req? A more general question is on the dependency between -req and -arch. On one hand, it is ideal to define -req first without a particular architecture to allow competing/alternative architectures satisfying the requirements. On the other hand, it appears that the -arch document contains content, in particular, systems/function components, that can be helpful to better understand the -req document. The current thinking is still to make -req independent of -arch, and move some general requirements in -arch to -req. Any comments? Q3: There are some good comments on reorganizing the -req documents. Below is a new structure (second level section #'s and page numbers are from the current -req so that others can see how we re-organize the document). Any comments/feedback before we start the revision will be greatly appreciated. Also, anyone who can help with direct revisions of the -req document will be more than welcome! Thanks. -- Richard 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 6 3. System/Functional Components 4. Requirements Structure . . . . . . . . . . . . . . . . . . . . 7 5. Data Object Requirements 4.5.1. Data Naming . . . . . . . . . . . . . . . . . . . . . .14 Move part of Arch 4.4 to -req 5.1. --Immutable Data . . . . . . . . . . . . . . . . . . . . 18 4.4.2. System Data Object Attributes . . . . . . . . . . . . .13 4.2.1. Data Object Size . . . . . . . . . . . . . . . . . 11 4.4.3. Time-to-live for Written Data Objects . . . . . . 13 4.4.4. Application-defined Properties and Metadata . . . . . 13 6. Access to Server Requirements 4.3.1. Read/Write Own Storage . . . . . . . . . . . . . . .. 11 4.3.2. Read/Write by Remote Clients . . . . . . . . . . . . . 11 4.4.5. Offline Access . . . . . . . . . . . . . . . . . . . 14 4.1.1.1. NATs and Firewalls TRaversal . . .. . . . . . . . . 8 Connections to Clients . . . . . . . . . . . . . . . . . . . 8 6.1.1. Support for Clients Behind NATs and Firewalls . . . 21 4.3.3. Negotiable Data Transport Protocol . . . . . . . . . . 12 5.2. Explicit Deletion of Data . . . . . . . . . . . . . . . 19 5.3. Concurrent Write (Multiple writing). . . . . . . . . . . 19 5.4. Concurrent Read (Multiple reading) . . . . . . . . . . . 19 5.5. Read While Write . . . . . . . . . . . . . . . . . . . 19 5.6. Partial Write (Writing model) . . . . . . . . . . . . . 20 4.1.2.1. Secure Transport . . . . . . . . . . . . . . . . . . 8 7. Resource Control Requirements. . . . . . . . . . . . . . . . . 15 4.6.1. Multiple Applications . . . . . . . . . . . . . . . . 15 4.6.2. Per-Remote-Client, Per-Data Control . . . . . . . . . 15 4.6.3. Resource Control Set . . . . . . . . . . . . . . . . . 16 4.6.4. Server Involvement . . . . . . . . . . . . . . . . . . 16 8. Authorization Requirements 4.7.1. Per-Remote-Client, Per-Data Read Access . . . . . . . 16 4.7.2. Per-User Write Access . . . . . . . . . . . . . . . . 17 4.7.3. Default Access Permissions . . . . . . . . . . . . . . 17 4.7.4. Authorization Checks . . . . . . . . . . . . . . . . . 17 4.7.5. Cryptographic Credentials . . . . . . . . . . . . . . 17 4.7.6. Server Involvement . . . . . . . . . . . . . . . . . . 18 4.7.7. Protocol Reuse . . . . . . . . . . . . . . . . . . . . 18 9. Error and Failure Handling Requirements. . . . . . . . . . . . 9 4.1.3.2. Insufficient Resources . . . . . . . . . . . . . . . 9 4.1.3.1. Overload Condition . . . . . . . . . . . . . . . 9 4.1.3.3. Unavailable and Deleted Data . . . . . . . . . . . . 10 4.1.3.4. Insufficient Permissions . . . . . . . . . . . . . . 10 4.1.3.5. Redirection . . . . . . . . . . . . . . . . . . . . 10 4.1.2.2. Gaming Prevention . . . . . . . . . . . . . . . . . .8 4.4.1. Server reliability (Agnostic of reliability) . . . . . 12 10. Server Status Query Requirements . . . . . . . . . . . . . . . 18 5.7. Storage Status . . . . . . . . . . . . . . . . . . . . . 20 .... 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7.1. Authentication and Authorization . . . . . . . . . . . . 21 7.2. Encrypted Data . . . . . . . . . . . . . . . . . . . . . 22 7.3. Protection against Gaming . . . . . . . . . . . . . . . 22