Subject: Re: [decade] Start of WGLC for draft-ietf-decade-problem-statement-02

From: Songhaibin <[email-masked]>
Date: Thu, 10 Feb 2011 08:23:01 +0000

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:[email-masked]]
Sent: Friday, January 28, 2011 10:42 PM
To: [email-masked]
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<http://google.com/search?q=define:acess>/access, s/chanllenge<http://google.com/search?q=define:chanllenge>/challenge
Section 5.4.2. s/Firgure<http://google.com/search?q=define:Firgure>/Figure
Appendix A. s/hetergeneous<http://google.com/search?q=define: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: [email-masked]
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, [email-masked]<mailto:[email-masked]>.

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

---

From: Songhaibin <[email-masked]>
Date: Thu, 10 Feb 2011 08:54:14 +0000

Hi Wesley,

Thank you for the comments. See my reply in line.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Wesley Eddy
> Sent: Saturday, January 29, 2011 12:59 AM
> To: Woundy, Richard; [email-masked]
> 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, [email-masked] <mailto:[email-masked]>.
> >
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/decade

---

From: Songhaibin <[email-masked]>
Date: Thu, 10 Feb 2011 08:55:24 +0000

Hi Akbar,

Thanks for the check.

BR,
Haibin

From: [email-masked] [mailto:[email-masked]] On Behalf Of Rahman, Akbar
Sent: Sunday, January 30, 2011 11:12 PM
To: Woundy, Richard
Cc: [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf Of Woundy, Richard
Sent: Friday, January 28, 2011 9:26 AM
To: [email-masked]
Subject: [decade] Start of WGLC for draft-ietf-decade-problem-statement-02

Folks,

Thanks.

-- Rich and Haibin

---

From: Lars Eggert <[email-masked]>
Date: Thu, 10 Feb 2011 15:27:36 +0200

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 (= 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/

---

From: Songhaibin <[email-masked]>
Date: Tue, 15 Feb 2011 06:19:08 +0000

Dear Las,

Thank you very much for the detailed review of this document.

> Of Lars Eggert
> Sent: Thursday, February 10, 2011 9:28 PM
> To: Woundy, Richard
> Cc: [email-masked]
> 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:
> 

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.

>   Surely you mean "Informational".

Agree.

>   introduction phrases this better.

OK. I think that also benefits the application users.

>   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.

>   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
Good comment. We should add text to explicitly say that "Content provider is also a user of in-network storage".

>   I thought this was a problem statement? It shouldn't introduce a

OK. I agree. It should reflect the main idea of this document.

>   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.

>   availability and access performance *for those chunks that are stored

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.

>   I'd remove the "to consumers" bit. It doesn't really matter who the

Good.

>   Add citations for those claims?

OK. Let me try to add them.

>   s/lacking/lack/ & s/crowd/crowds/ & s/begin/that begin/

Thank you very much. I will check the whole document for such nits.

>   overload an existing term?

Okay.

>   Nit: s/during flash crowd/during a flash crowd/

Okay.

>   Nit: s/the more// & s/their// & s/in selecting/to select/ & s/the

Okay.

>   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:().

>   storage box to download the piece from B's in-network storage box",

Yes.

>   storage box, or is it actually A's in-network storage box that sends

It could be in either way.

>   can use their in-network storage for chunks retrieved from the content

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.

>   now compared to Figure 2.

OK. And I will change the figure a little bit.

>   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: )

> >       Peers.  The off-net PPSP Peers (ie end users) will be able to

Okay.

> >       The off-net PPSP Peers (ie end users) will be able to get chunks
Okay.

>   Nit: s/hetergeneous/heterogeneous/
Okay.

Thank you again. You did a very valuable review to this document.

Haibin