From haibin.song@huawei.com Thu Feb 10 00:23:10 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDB1E3A6923 for ; Thu, 10 Feb 2011 00:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.494 X-Spam-Level: X-Spam-Status: No, score=-4.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Q9dJAyMs4yq for ; Thu, 10 Feb 2011 00:23:05 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id E25533A6915 for ; Thu, 10 Feb 2011 00:23:01 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGE00MP17AFXN@szxga03-in.huawei.com> for decade@ietf.org; Thu, 10 Feb 2011 16:23:03 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGE007YQ7AE1P@szxga03-in.huawei.com> for decade@ietf.org; Thu, 10 Feb 2011 16:23:03 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 10 Feb 2011 16:21:08 +0800 Received: from SZXEML505-MBS.china.huawei.com ([169.254.1.213]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Thu, 10 Feb 2011 16:23:02 +0800 Date: Thu, 10 Feb 2011 08:23:01 +0000 From: Songhaibin In-reply-to: <1CA25301D2219F40B3AA37201F0EACD113400F18@PACDCEXMB05.cable.comcast.com> X-Originating-IP: [10.138.41.70] To: "Woundy, Richard" , "decade@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Tot5yzyoajAJQBtImvh+Tg)" Content-language: zh-CN Accept-Language: en-US, zh-CN Thread-topic: Start of WGLC for draft-ietf-decade-problem-statement-02 Thread-index: Acu+91Byr8CuZlwMSYaaxFnqkg41DwAAarbgAoCehEA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <1CA25301D2219F40B3AA37201F0EACD113400F18@PACDCEXMB05.cable.comcast.com> Subject: Re: [decade] Start of WGLC for draft-ietf-decade-problem-statement-02 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 08:23:10 -0000 --Boundary_(ID_Tot5yzyoajAJQBtImvh+Tg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Rich, Sorry for the late reply. I'm just back from the holidays. Thanks for the comments. The issues will be corrected in the new version after this round of WGLC. BR, Haibin From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Friday, January 28, 2011 10:42 PM To: decade@ietf.org Cc: Songhaibin; Woundy, Richard Subject: RE: Start of WGLC for draft-ietf-decade-problem-statement-02 Below are my personal comments on the DECADE Problem Statement draft. Please do not make any changes to the draft at this time; I would like the authors to incorporate these comments after WGLC. Misspelled words identified from the Idspell Tool, http://tools.ietf.org/tools/idspell/webservice. Section 3. s/acess/access, s/chanllenge/challenge Section 5.4.2. s/Firgure/Figure Appendix A. s/hetergeneous/heterogeneous >From idnits, http://tools.ietf.org/tools/idnits/ idnits 2.12.05 tmp/draft-ietf-decade-problem-statement-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to http://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- No issues found here. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. No nits found. -------------------------------------------------------------------------------- -- Rich From: Woundy, Richard Sent: Friday, January 28, 2011 9:26 AM To: decade@ietf.org Cc: Songhaibin; Woundy, Richard Subject: Start of WGLC for draft-ietf-decade-problem-statement-02 Folks, Haibin and I are starting the working group last call for draft-ietf-decade-problem-statement-02, http://datatracker.ietf.org/doc/draft-ietf-decade-problem-statement/, to be completed by Monday February 14. Please send all concerns, suggestions and comments about this internet-draft to the DECADE mailing list, decade@ietf.org. Authors, please do not make any additional changes to the internet-draft unless directed by the WG chairs. Draft reviewers, it would be helpful to get your confirmation that your previous review comments have been correctly reflected in this version. Thanks. -- Rich and Haibin --Boundary_(ID_Tot5yzyoajAJQBtImvh+Tg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi Rich,

 

Sorry for the late reply. I’m just back from the holidays.

 

Thanks for the comments. The issues will be corrected in the new = version after this round of WGLC.

 

BR,

Haibin

 

From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.= com]
Sent: Friday, January 28, 2011 10:42 PM
To: decade@ietf.org
Cc: Songhaibin; Woundy, Richard
Subject: RE: Start of WGLC for draft-ietf-decade-problem-statement-0= 2

 

Below a= re my personal comments on the DECADE Problem Statement draft. Please do no= t make any changes to the draft at this time; I would like the authors to i= ncorporate these comments after WGLC.

&n= bsp;

Misspel= led words identified from the Idspell Tool, http://tools.iet= f.org/tools/idspell/webservice.

&n= bsp;

Section= 3. s/acess/access, s/chanllenge/challenge

Section= 5.4.2. s/Firgure/Figure<= o:p>

Appendi= x A. s/hetergeneous/heterogeneous

&n= bsp;

From id= nits, http://tools.ietf.org/tools/idnits/

&n= bsp;

idnits = 2.12.05

&n= bsp;

tmp/dra= ft-ietf-decade-problem-statement-02.txt:

&n= bsp;

  = Checking boilerplate required by RFC 5378 and the IETF Trust (see

  = http://trustee.ietf.org/license-info):

  = ---------------------------------------------------------------------------= -

&n= bsp;

 &= nbsp;   No issues found here.

&n= bsp;

  = Checking nits according to http://www.ietf.= org/id-info/1id-guidelines.txt:

  = ---------------------------------------------------------------------------= -

&n= bsp;

 &= nbsp;   No issues found here.

&n= bsp;

  = Checking nits according to http://www.ietf.org/id-in= fo/checklist :

  = ---------------------------------------------------------------------------= -

&n= bsp;

 &= nbsp;   No issues found here.

&n= bsp;

  = Miscellaneous warnings:

  = ---------------------------------------------------------------------------= -

&n= bsp;

 &= nbsp;   No issues found here.

&n= bsp;

  = Checking references for intended status: Proposed Standard

  = ---------------------------------------------------------------------------= -

&n= bsp;

 &= nbsp;   (See RFCs 3967 and 4897 for information about using norma= tive references

 &= nbsp;   to lower-maturity documents in RFCs)

&n= bsp;

 &= nbsp;   No issues found here.

&n= bsp;

 &= nbsp;   No nits found.

-------= -------------------------------------------------------------------------

&n= bsp;

-- Rich=

&n= bsp;

From: Woundy, Richard
Sent: Friday, January 28, 2011 9:26 AM
To: decade@ietf.org
Cc: Songhaibin; Woundy, Richard
Subject: Start of WGLC for draft-ietf-decade-problem-statement-02

 

Folks,

 

Haibin and I are starting the w= orking group last call for draft-ietf-decade-problem-statement-02, http://datatracker.ietf.org/doc/draft-ietf-decade-problem-statement/<= /a>, to be completed by Monday February 14. Please send all concerns, sugge= stions and comments about this internet-draft to the DECADE mailing list, decade@ietf= .org.

 

Authors, please do not make any= additional changes to the internet-draft unless directed by the WG chairs.=

 

Draft reviewers, it would be he= lpful to get your confirmation that your previous review comments have been= correctly reflected in this version.

 

Thanks.

 

-- Rich and Haibin

--Boundary_(ID_Tot5yzyoajAJQBtImvh+Tg)-- From haibin.song@huawei.com Thu Feb 10 00:54:22 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CAB23A69B7 for ; Thu, 10 Feb 2011 00:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wt1OXoOtyvTJ for ; Thu, 10 Feb 2011 00:54:21 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 8ACDA3A693C for ; Thu, 10 Feb 2011 00:54:21 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGE00HDL8QM71@szxga03-in.huawei.com> for decade@ietf.org; Thu, 10 Feb 2011 16:54:22 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGE00HJK8QMB5@szxga03-in.huawei.com> for decade@ietf.org; Thu, 10 Feb 2011 16:54:22 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 10 Feb 2011 16:52:28 +0800 Received: from SZXEML505-MBS.china.huawei.com ([169.254.1.213]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Thu, 10 Feb 2011 16:54:15 +0800 Date: Thu, 10 Feb 2011 08:54:14 +0000 From: Songhaibin In-reply-to: <4D42F5BC.2030900@mti-systems.com> X-Originating-IP: [10.138.41.70] To: Wesley Eddy , "Woundy, Richard" , "decade@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [decade] Start of WGLC for draft-ietf-decade-problem-statement-02 Thread-index: AQHLvwzq31Ys2diXA0qQnQG0stC/Z5P6eXLw X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <4D42F5BC.2030900@mti-systems.com> Subject: Re: [decade] Start of WGLC for draft-ietf-decade-problem-statement-02 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 08:54:22 -0000 Hi Wesley, Thank you for the comments. See my reply in line. > -----Original Message----- > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf > Of Wesley Eddy > Sent: Saturday, January 29, 2011 12:59 AM > To: Woundy, Richard; decade@ietf.org > Subject: Re: [decade] Start of WGLC for > draft-ietf-decade-problem-statement-02 > > On 1/28/2011 9:26 AM, Woundy, Richard wrote: > > Folks, > > > > Haibin and I are starting the working group last call for > > draft-ietf-decade-problem-statement-02, > > http://datatracker.ietf.org/doc/draft-ietf-decade-problem-statement/, to > > be completed by Monday February 14. Please send all concerns, > > suggestions and comments about this internet-draft to the DECADE mailing > > list, decade@ietf.org . > > > > Here are some comments: > > The intended status should be "Informational" and not "Standards Track". > You are right. It will be corrected in next version. > This document is more than just a problem statement; it also includes > description of the solution approach that DECADE is pursuing. > This high level solution space is in the scope of the charter. Please refer to http://tools.ietf.org/wg/decade/charters. And it is for the heuristic purpose. If you have any specific comments with the contents, please let me know. > The document needs to provide more context about what "in-network" > means, since in the context of the document it seems to specifically > mean resources provided by an ISP. I'm not sure if the work is > applicable to nodes that are merely "on a network" providing services, > rather than "inside a network". This is important to understand, as it > is central to the entire document (and DECADE) and it influences > applicability. > IMO "in-network" means the storage nodes are inside a network provided by the network operator. That is why it can save last mile uplink bandwidth for peer to peer applications(write once, read multiple times). > (editorial) Section 1, paragraph 2 - "to effectively utilize" -> "from > effectively utilizing" > > (editorial) Make sure "P2P" and "p2p" are used consistently (one or the > other). > > (editorial) "flash crowd" versus "flash crowds" should be checked for > usage in multiple places > > Thank you very much for these editorial comments. Sorry for the late reply. Haibin > > > > -- > Wes Eddy > MTI Systems > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade From haibin.song@huawei.com Thu Feb 10 00:55:26 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86B303A693B for ; Thu, 10 Feb 2011 00:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TcHvke8wQ0D for ; Thu, 10 Feb 2011 00:55:25 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 610963A6933 for ; Thu, 10 Feb 2011 00:55:25 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGE00FQM8SEX3@szxga05-in.huawei.com> for decade@ietf.org; Thu, 10 Feb 2011 16:55:26 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGE006HN8SDQV@szxga05-in.huawei.com> for decade@ietf.org; Thu, 10 Feb 2011 16:55:26 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 10 Feb 2011 16:55:18 +0800 Received: from SZXEML505-MBS.china.huawei.com ([169.254.1.213]) by SZXEML401-HUB.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Thu, 10 Feb 2011 16:55:24 +0800 Date: Thu, 10 Feb 2011 08:55:24 +0000 From: Songhaibin In-reply-to: X-Originating-IP: [10.138.41.70] To: "Rahman, Akbar" , "Woundy, Richard" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_SExHJK37q4Lk25Z49r4mWg)" Content-language: zh-CN Accept-Language: en-US, zh-CN Thread-topic: [decade] Start of WGLC for draft-ietf-decade-problem-statement-02 Thread-index: AQHLwJA5SW0m3Pbe5UepS9TmJVQIV5P6fzzw X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> Cc: "decade@ietf.org" Subject: Re: [decade] Start of WGLC for draft-ietf-decade-problem-statement-02 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 08:55:26 -0000 --Boundary_(ID_SExHJK37q4Lk25Z49r4mWg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Akbar, Thanks for the check. BR, Haibin From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Rahman, Akbar Sent: Sunday, January 30, 2011 11:12 PM To: Woundy, Richard Cc: decade@ietf.org Subject: Re: [decade] Start of WGLC for draft-ietf-decade-problem-statement-02 Hi Rich, I have reviewed the decade problem statement (rev. 02) and confirm that it addresses all the comments that I had raised in my review of the document (rev. 00). Thanks to all the authors of the draft for doing a good job on the update. Sincerely, Akbar From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Woundy, Richard Sent: Friday, January 28, 2011 9:26 AM To: decade@ietf.org Subject: [decade] Start of WGLC for draft-ietf-decade-problem-statement-02 Folks, Haibin and I are starting the working group last call for draft-ietf-decade-problem-statement-02, http://datatracker.ietf.org/doc/draft-ietf-decade-problem-statement/, to be completed by Monday February 14. Please send all concerns, suggestions and comments about this internet-draft to the DECADE mailing list, decade@ietf.org. Authors, please do not make any additional changes to the internet-draft unless directed by the WG chairs. Draft reviewers, it would be helpful to get your confirmation that your previous review comments have been correctly reflected in this version. Thanks. -- Rich and Haibin --Boundary_(ID_SExHJK37q4Lk25Z49r4mWg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi Akbar,

 

Thanks for the check.

 

BR,

Haibin

 

From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.o= rg] On Behalf Of Rahman, Akbar
Sent: Sunday, January 30, 2011 11:12 PM
To: Woundy, Richard
Cc: decade@ietf.org
Subject: Re: [decade] Start of WGLC for draft-ietf-decade-problem-st= atement-02

 

Hi Rich= ,

&n= bsp;

&n= bsp;

I have = reviewed the decade problem statement (rev. 02) and confirm that it address= es all the comments that I had raised in my review of the document (rev. 00= ).  Thanks to all the authors of the draft for doing a good job on the update.

&n= bsp;

&n= bsp;

Sincere= ly,

&n= bsp;

Akbar

&n= bsp;

From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.o= rg] On Behalf Of Woundy, Richard
Sent: Friday, January 28, 2011 9:26 AM
To: decade@ietf.org
Subject: [decade] Start of WGLC for draft-ietf-decade-problem-statem= ent-02

 

Folks,

 

Haibin and I are starting the w= orking group last call for draft-ietf-decade-problem-statement-02, http://datatracker.ietf.org/doc/draft-ietf-decade-problem-statement/<= /a>, to be completed by Monday February 14. Please send all concerns, sugge= stions and comments about this internet-draft to the DECADE mailing list, decade@ietf= .org.

 

Authors, please do not make any= additional changes to the internet-draft unless directed by the WG chairs.=

 

Draft reviewers, it would be he= lpful to get your confirmation that your previous review comments have been= correctly reflected in this version.

 

Thanks.

 

-- Rich and Haibin

--Boundary_(ID_SExHJK37q4Lk25Z49r4mWg)-- From lars.eggert@nokia.com Thu Feb 10 05:27:44 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E3A13A69A4 for ; Thu, 10 Feb 2011 05:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=1.130, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uF83Ixk2GqqB for ; Thu, 10 Feb 2011 05:27:42 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 8BFA03A6984 for ; Thu, 10 Feb 2011 05:27:42 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1ADRn4l023730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Feb 2011 15:27:50 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.5 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-55--937806688; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> Date: Thu, 10 Feb 2011 15:27:36 +0200 Message-Id: <03EF6997-73A2-4F65-923C-ECF8836EEA76@nokia.com> References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> To: "Woundy, Richard" X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Thu, 10 Feb 2011 15:27:42 +0200 (EET) X-Nokia-AV: Clean Cc: "decade@ietf.org" Subject: Re: [decade] Start of WGLC for draft-ietf-decade-problem-statement-02 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 13:27:44 -0000 --Apple-Mail-55--937806688 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I had a few minutes to give this document a read. Basically, this is on = the right track but has remaining issues. The key ones are: - should be Informational - has too much architecture in it for a problem statement (Sections 4 & = 5) - problem statement itself mostly reiterates what the charter already = contained, had hoped for more detailed analysis Lars Note: Most comments marked as "nits" below have been automatically flagged by review scripts - there may be some false positives in there. INTRODUCTION, paragraph 1: > Intended status: Standards Track Surely you mean "Informational". INTRODUCTION, paragraph 5: > Peer-to-peer (P2P) applications have become widely used on the > Internet today and make up a large portion of the traffic in many > networks. In P2P applications, one technique for reducing the = total > amount of P2P traffic is to introduce storage capabilities within = the > network. The *total* amount of traffic isn't being reduced - the total amount of traffic *traversing the access networks* may be reduced with in-network storage. (The total amount of traffic may even increase, because the in-network storage is likely much better connected.) The introduction phrases this better. INTRODUCTION, paragraph 6: > Traditional caches (e.g., P2P and Web caches) provide such > storage, but they are complex (due to explicitly supporting > individual P2P application protocols) and they do not allow users = to > manage access to content in the cache. I'm not sure if complex is the right word here. Sure, they are P2P-app-specific, and if they want to support several P2P apps, complexity results. But not allowing the users to manage access to content actually makes them *less* complex (compared to a solution that has those features.) INTRODUCTION, paragraph 7: > For example, Content > Providers cannot easily control access and resource usage policies = to > satisfy their own requirements. Based on the previous sections, I don't see what that is an example for? Also, the rest of the document never talks about providers being able to apply policies, it only says that *users* can. Section 1., paragraph 5: > This document introduces DECADE, a standard interface for various = P2P > applications to access storage and data transport services in the > network to improve their efficiency and reduce load on the network > infrastructure. I thought this was a problem statement? It shouldn't introduce a solution. Section 1., paragraph 8: > And further, either the existing P2P cache or any new type of in- > network storage should be deployed near the edge of the ISP's = network > so as to gain better performance. Is this paragraph left over from an earlier editing pass? It has no connection to the previous paragraphs. Section 2., paragraph 2: > In-network Storage: A service inside a network that provides > storage and bandwidth to network applications. In-network = storage > may reduce upload/transit/backbone traffic and improve network > application performance. It doesn't really provide "bandwidth." It provides increased availability and access performance *for those chunks that are stored there*. Section 2., paragraph 5: > Content Publisher: An entity that originates content to = consumers. I'd remove the "to consumers" bit. It doesn't really matter who the content is provided for. Section 3., paragraph 1: > For example, CNN > reported that P2P streaming by Octoshape played a major role in its > distribution of the historical inauguration address of President > Obama. PPLive, one of the largest P2P streaming vendors, is able = to > distribute large-scale, live streaming programs to more than 2 > million users with only a handful of servers. Add citations for those claims? > However, P2P applications also face substantial design challenges. = A > particular problem facing P2P applications is the substantial = stress > that they place on the network infrastructure. Also, lacking of > infrastructure support can lead to unstable P2P application > performance during peer churns and flash crowd. Here flash crowd > means a large group of application users begin to acess the same > service during a very short period of time, which is a chanllenge = to > the system. Below we elaborate on the problems in more detail. Please proof-read this document again. Language nits in this paragraph alone: s/chanllenge/challenge/ & s/acess/access/ & s/churns/churn/ & s/lacking/lack/ & s/crowd/crowds/ & s/begin/that begin/ Section 3.1., paragraph 1: > Furthermore, network-agnostic peering leads to unnecessary = traversal > across network domains or spanning the backbone of a network, = leading > to network inefficiency [RFC5693]. I was thrown off by the "peering" term. I guess you mean "p2p transmissions" and not BGP-level peering? Can you rephrase and not overload an existing term? Section 3.3., paragraph 1: > additional in-network resources during flash crowd, such as just Nit: s/during flash crowd/during a flash crowd/ Section 3.3., paragraph 3: > A requirement by some P2P applications in using in-network > infrastructural resources, however, is flexibility in implementing > resource allocation policies. A major competitive advantage of = many > successful P2P systems is their substantial expertise in how to = most > efficiently utilize peer and infrastructural resources. For = example, > many live P2P systems have their specific algorithms in selecting = the > peers that behave as the more stable, higher bandwidth sources. = They Nit: s/the more// & s/their// & s/in selecting/to select/ & s/the peer/those peers/ Section 4.2., paragraph 1: > DECADE ensures that access to the in-network storage is subject to > authorization by the user owning the in-network storage service. Users won't "own" in-network storage devices. ISPs will make a storage facility available to a user, and that user may manage and use it. but not "own" it. Or do you mean that the ISP will authorize access? Section 5.1., paragraph 2: > We now describe in more detail how BitTorrent can utilize DECADE. > For illustration, we assume that both the BitTorrent client (A) and > its peer (B) utilize in-network storage. When A requests a block, = it > indicates that it would like the block stored in its in-network > storage and provides the necessary access control. Instead of > sending the 'piece' message with the desired block, peer B replies > with a 'redirect' message indicating that the content should be > retrieved from its own in-network storage and provides the = necessary > access control. If the peer B had not previously stored the = content > in its in-network storage, it uploads the block. A downloads the > block into its own in-network storage from B's in-network storage, > and finally A itself retrieves the block. In the last sentence, I guess you mean "A instructs its in-network storage box to download the piece from B's in-network storage box", right? Section 5.1., paragraph 5: > Redirection to a DECADE server does not only need to come from a > peer. In this case, in order to avoid the connectivity issue = brought > by NATs, B can also attach its in-network storage address in the > message to its tracker. When A sends the content request message > with the content ID to the tracker, the tracker replies with B's = in- > network storage address and the BitMap info. Then A sends a = request > using IAP protocol to B's in-network storage for the pieces of this > content, with the unique identity of the content in the storage. In the last sentence, is it really A that talks to B's in-network storage box, or is it actually A's in-network storage box that sends the request? Section 5.3., paragraph 0: > 5.3. CDN/P2P hybrid Isn't this use case identical to 5.2? 5.2 already discusses that peers can use their in-network storage for chunks retrieved from the content provider (=3D the CDN). Section 5.4.2., paragraph 3: > Firgure 3: Usage Scenario 2 (Sender account used) s/Firgure/Figure/ & also it's confusing that Sa is on the other side now compared to Figure 2. Appendix A., paragraph 0: > Appendix A. Other Related Work in IETF I see little value in including this appendix, given the extremely slow progress of the PPSP WG. Appendix A., paragraph 5: > Peers. The off-net PPSP Peers (ie end users) will be able to = get Nit: s/(ie/(i.e.,/ Appendix A., paragraph 7: > The off-net PPSP Peers (ie end users) will be able to get chunks Nit: s/(ie/(i.e.,/ Appendix A., paragraph 9: > hetergeneous networks including both fixed and mobile = connections Nit: s/hetergeneous/heterogeneous/ --Apple-Mail-55--937806688 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDIxMDEzMjczN1owIwYJKoZIhvcNAQkE MRYEFPeVVS74nKu4VbNc4WY8kIXPhZMGMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB ADSyQIGP3zz+gTBvMam1Ps4dAltDUCKIzwpjHd8p3GQQQxTVqVyRt/J/4TMCraKbHSuyR6wZYbfY N/1BrV5ri6TXObzHOjz6qiIzJwyP470zzDtBELa9LP8PJPHtnCVXsgivNJ65/oz8ayiFB/SSmn1/ Nq+cOXzYdM7wRziSCudFn1L8IdyTWuudEdWz4XCLAmMMbnsABCgMgFK/6or7Ar1IvlZM3Vien9lM x52N/tQYGJMD0Va0V/YFN6XnbPBxsugl88zxmQ15X8fplKy30YUd5iNkoDG8VI6aCBerwxqwaftf gWI/Coi8Iy9P3wDct1pd4WD1YMfscIsO85nvj8oAAAAAAAA= --Apple-Mail-55--937806688-- From haibin.song@huawei.com Mon Feb 14 22:18:59 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52CA93A6C66 for ; Mon, 14 Feb 2011 22:18:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.228 X-Spam-Level: X-Spam-Status: No, score=-3.228 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_44=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gW0UtgacYQam for ; Mon, 14 Feb 2011 22:18:56 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id CA0353A6A9E for ; Mon, 14 Feb 2011 22:18:55 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGN00I4OAVXR8@szxga04-in.huawei.com> for decade@ietf.org; Tue, 15 Feb 2011 14:19:09 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGN00EO4AVXHZ@szxga04-in.huawei.com> for decade@ietf.org; Tue, 15 Feb 2011 14:19:09 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 15 Feb 2011 14:17:02 +0800 Received: from SZXEML505-MBS.china.huawei.com ([169.254.1.213]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Tue, 15 Feb 2011 14:19:09 +0800 Date: Tue, 15 Feb 2011 06:19:08 +0000 From: Songhaibin In-reply-to: <03EF6997-73A2-4F65-923C-ECF8836EEA76@nokia.com> X-Originating-IP: [10.138.41.70] To: Lars Eggert , "Woundy, Richard" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [decade] Start of WGLC for draft-ietf-decade-problem-statement-02 Thread-index: AQHLySadWeUdUstchkWXpV8A2sr4y5QB5j/A X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1CA25301D2219F40B3AA37201F0EACD113400ECC@PACDCEXMB05.cable.comcast.com> <03EF6997-73A2-4F65-923C-ECF8836EEA76@nokia.com> Cc: "decade@ietf.org" Subject: Re: [decade] Start of WGLC for draft-ietf-decade-problem-statement-02 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 06:18:59 -0000 Dear Las, Thank you very much for the detailed review of this document. > -----Original Message----- > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf > Of Lars Eggert > Sent: Thursday, February 10, 2011 9:28 PM > To: Woundy, Richard > Cc: decade@ietf.org > Subject: Re: [decade] Start of WGLC for > draft-ietf-decade-problem-statement-02 > > Hi, > > I had a few minutes to give this document a read. Basically, this is on the right > track but has remaining issues. The key ones are: > > - should be Informational > I agree. > - has too much architecture in it for a problem statement (Sections 4 & 5) > I agree there is much text about use cases on how to use in-network storage(section 5). But the thought is that we do not want the final solution space be widely open and at the same time, we do not want to touch the detailed design. > - problem statement itself mostly reiterates what the charter already > contained, had hoped for more detailed analysis > Thanks. As the authors are trying our best to make this document convincing, we would also be happy to hear any comments on the detailed points. > Lars > > > Note: Most comments marked as "nits" below have been automatically > flagged by review scripts - there may be some false positives in there. > > > INTRODUCTION, paragraph 1: > > Intended status: Standards Track > > Surely you mean "Informational". > Agree. > > INTRODUCTION, paragraph 5: > > Peer-to-peer (P2P) applications have become widely used on the > > Internet today and make up a large portion of the traffic in many > > networks. In P2P applications, one technique for reducing the total > > amount of P2P traffic is to introduce storage capabilities within the > > network. > > The *total* amount of traffic isn't being reduced - the total amount > of traffic *traversing the access networks* may be reduced with > in-network storage. (The total amount of traffic may even increase, > because the in-network storage is likely much better connected.) The > introduction phrases this better. > OK. I think that also benefits the application users. > > INTRODUCTION, paragraph 6: > > Traditional caches (e.g., P2P and Web caches) provide such > > storage, but they are complex (due to explicitly supporting > > individual P2P application protocols) and they do not allow users to > > manage access to content in the cache. > > I'm not sure if complex is the right word here. Sure, they are > P2P-app-specific, and if they want to support several P2P apps, > complexity results. But not allowing the users to manage access to > content actually makes them *less* complex (compared to a solution > that has those features.) > Good comment. I think we need more text to say that it is the cache refreshing mechanisms make it complex. Managing access to content in the cache is the feature that does not provide by the existing cache. > > INTRODUCTION, paragraph 7: > > For example, Content > > Providers cannot easily control access and resource usage policies to > > satisfy their own requirements. > > Based on the previous sections, I don't see what that is an example > for? Perhaps we need to reorganize the text a little bit. That is one drawback of the existing cache. > Also, the rest of the document never talks about providers being > able to apply policies, it only says that *users* can. > Good comment. We should add text to explicitly say that "Content provider is also a user of in-network storage". > > Section 1., paragraph 5: > > This document introduces DECADE, a standard interface for various P2P > > applications to access storage and data transport services in the > > network to improve their efficiency and reduce load on the network > > infrastructure. > > I thought this was a problem statement? It shouldn't introduce a > solution. > OK. I agree. It should reflect the main idea of this document. > > Section 1., paragraph 8: > > And further, either the existing P2P cache or any new type of in- > > network storage should be deployed near the edge of the ISP's network > > so as to gain better performance. > > Is this paragraph left over from an earlier editing pass? It has no > connection to the previous paragraphs. > This paragraph was added after a valuable comment from the list. It is to reflect the idea of a reference draft(draft-weaver-alto-edge-caches). I'm also not sure about where to add this text, but a separate paragraph in the introduction section might be okay. > > Section 2., paragraph 2: > > In-network Storage: A service inside a network that provides > > storage and bandwidth to network applications. In-network > storage > > may reduce upload/transit/backbone traffic and improve network > > application performance. > > It doesn't really provide "bandwidth." It provides increased > availability and access performance *for those chunks that are stored > there*. > There is an implication that the application can request the amount of bandwidth(as we say that it supports resource control). But I think you are also right that "It provides increased availability and access performance for those chunks stored there". I will revise the text. > > Section 2., paragraph 5: > > Content Publisher: An entity that originates content to consumers. > > I'd remove the "to consumers" bit. It doesn't really matter who the > content is provided for. > Good. > > Section 3., paragraph 1: > > For example, CNN > > reported that P2P streaming by Octoshape played a major role in its > > distribution of the historical inauguration address of President > > Obama. PPLive, one of the largest P2P streaming vendors, is able to > > distribute large-scale, live streaming programs to more than 2 > > million users with only a handful of servers. > > Add citations for those claims? OK. Let me try to add them. > > > However, P2P applications also face substantial design challenges. A > > particular problem facing P2P applications is the substantial stress > > that they place on the network infrastructure. Also, lacking of > > infrastructure support can lead to unstable P2P application > > performance during peer churns and flash crowd. Here flash crowd > > means a large group of application users begin to acess the same > > service during a very short period of time, which is a chanllenge to > > the system. Below we elaborate on the problems in more detail. > > Please proof-read this document again. Language nits in this paragraph > alone: s/chanllenge/challenge/ & s/acess/access/ & s/churns/churn/ & > s/lacking/lack/ & s/crowd/crowds/ & s/begin/that begin/ > Thank you very much. I will check the whole document for such nits. > > Section 3.1., paragraph 1: > > Furthermore, network-agnostic peering leads to unnecessary traversal > > across network domains or spanning the backbone of a network, leading > > to network inefficiency [RFC5693]. > > I was thrown off by the "peering" term. I guess you mean "p2p > transmissions" and not BGP-level peering? Can you rephrase and not > overload an existing term? > Okay. > > Section 3.3., paragraph 1: > > additional in-network resources during flash crowd, such as just > > Nit: s/during flash crowd/during a flash crowd/ > Okay. > > Section 3.3., paragraph 3: > > A requirement by some P2P applications in using in-network > > infrastructural resources, however, is flexibility in implementing > > resource allocation policies. A major competitive advantage of many > > successful P2P systems is their substantial expertise in how to most > > efficiently utilize peer and infrastructural resources. For example, > > many live P2P systems have their specific algorithms in selecting the > > peers that behave as the more stable, higher bandwidth sources. > > They > > Nit: s/the more// & s/their// & s/in selecting/to select/ & s/the > peer/those peers/ > Okay. > > Section 4.2., paragraph 1: > > DECADE ensures that access to the in-network storage is subject to > > authorization by the user owning the in-network storage service. > > Users won't "own" in-network storage devices. ISPs will make a storage > facility available to a user, and that user may manage and use it. but > not "own" it. Or do you mean that the ISP will authorize access? > Good comment. ISPs provide the devices, and application/ordinary users are granted to rent them, and these application/ordinary users can also authorize other users to read/write to "their" in-network storage. The word "own" may not be a most appropriate choice, but I do not have another better word in mind(poor English speaker:(). > > Section 5.1., paragraph 2: > > We now describe in more detail how BitTorrent can utilize DECADE. > > For illustration, we assume that both the BitTorrent client (A) and > > its peer (B) utilize in-network storage. When A requests a block, it > > indicates that it would like the block stored in its in-network > > storage and provides the necessary access control. Instead of > > sending the 'piece' message with the desired block, peer B replies > > with a 'redirect' message indicating that the content should be > > retrieved from its own in-network storage and provides the necessary > > access control. If the peer B had not previously stored the content > > in its in-network storage, it uploads the block. A downloads the > > block into its own in-network storage from B's in-network storage, > > and finally A itself retrieves the block. > > In the last sentence, I guess you mean "A instructs its in-network > storage box to download the piece from B's in-network storage box", > right? > Yes. > > Section 5.1., paragraph 5: > > Redirection to a DECADE server does not only need to come from a > > peer. In this case, in order to avoid the connectivity issue brought > > by NATs, B can also attach its in-network storage address in the > > message to its tracker. When A sends the content request message > > with the content ID to the tracker, the tracker replies with B's in- > > network storage address and the BitMap info. Then A sends a request > > using IAP protocol to B's in-network storage for the pieces of this > > content, with the unique identity of the content in the storage. > > In the last sentence, is it really A that talks to B's in-network > storage box, or is it actually A's in-network storage box that sends > the request? > It could be in either way. > > Section 5.3., paragraph 0: > > 5.3. CDN/P2P hybrid > > Isn't this use case identical to 5.2? 5.2 already discusses that peers > can use their in-network storage for chunks retrieved from the content > provider (= the CDN). > Content provider/publisher is a little different from the content distribution network. But if you look them both as the source of the content for DECADE storage, then I agree these two sections are very similar. > > Section 5.4.2., paragraph 3: > > Firgure 3: Usage Scenario 2 (Sender account used) > > s/Firgure/Figure/ & also it's confusing that Sa is on the other side > now compared to Figure 2. OK. And I will change the figure a little bit. > > > Appendix A., paragraph 0: > > Appendix A. Other Related Work in IETF > > I see little value in including this appendix, given the extremely > slow progress of the PPSP WG. > The appendix as a background, also talks about how PPSP and DECADE can work simultaneously. And it is only on the conceptual level, so the slow progress of PPSP WG does not matter here: ) > > Appendix A., paragraph 5: > > Peers. The off-net PPSP Peers (ie end users) will be able to > > get > > Nit: s/(ie/(i.e.,/ > Okay. > > Appendix A., paragraph 7: > > The off-net PPSP Peers (ie end users) will be able to get chunks > > Nit: s/(ie/(i.e.,/ > Okay. > > Appendix A., paragraph 9: > > hetergeneous networks including both fixed and mobile > > connections > > Nit: s/hetergeneous/heterogeneous/ > Okay. Thank you again. You did a very valuable review to this document. Haibin From richard_woundy@cable.comcast.com Mon Feb 28 09:15:11 2011 Return-Path: X-Original-To: decade@core3.amsl.com Delivered-To: decade@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C03393A6A10 for ; Mon, 28 Feb 2011 09:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.879 X-Spam-Level: X-Spam-Status: No, score=-103.879 tagged_above=-999 required=5 tests=[AWL=-2.144, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDBM3gUP9cNq for ; Mon, 28 Feb 2011 09:15:11 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 047413A69FC for ; Mon, 28 Feb 2011 09:15:10 -0800 (PST) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.27572642; Mon, 28 Feb 2011 10:28:01 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0270.001; Mon, 28 Feb 2011 12:16:07 -0500 From: "Woundy, Richard" To: "decade@ietf.org" Thread-Topic: DECADE - Requested session has been scheduled for IETF 80 Thread-Index: AQHL1HMCj46JxNAg30KUXCDUGlb3eJQXCyGw Date: Mon, 28 Feb 2011 17:16:06 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD11343A966@PACDCEXMB05.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.25.250.96] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [decade] FW: DECADE - Requested session has been scheduled for IETF 80 X-BeenThere: decade@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "To start the discussion on DECoupled Application Data Enroute, to discuss the in-network data storage for p2p applications and its access protocol" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 17:15:11 -0000 QmVsb3cgaXMgdGhlIHRlbnRhdGl2ZSBzY2hlZHVsZSBmb3IgdGhlIERFQ0FERSBtZWV0aW5nIGlu IFByYWd1ZS4NCg0KPkRFQ0FERSBTZXNzaW9uIDEgKDIgaG91cnMpDQo+TW9uZGF5LCBBZnRlcm5v b24gU2Vzc2lvbiBJIDEzMDAtMTUwMA0KPlJvb20gTmFtZTogR3JhbmQgQmFsbHJvb20NCg0KLS0g UmljaA0K