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

[Lars Eggert <[e-mail]>]

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/