[ppsp] An early AD review of draft-ietf-ppsp-problem-statement-10.txt

[Martin Stiemerling <[e-mail]>]

Dear all,

I have seen the update of the draft 
draft-ietf-ppsp-problem-statement-10.txt.

I did a first round of my review that you can find below. It is up to 
Section 6.3, but not including this section.

There are a number of editorials, but also some more technical 
questions. I guess we need to discuss some of them here on the list.

The first half of the review:


INTRODUCTION, paragraph 4:

 >    Peer-to-Peer (P2P for short) streaming systems show more and more
 >    popularity in current Internet with proprietary protocols. This
 >    document identifies problems of the proprietary protocols, proposes a
 >    Peer to Peer Streaming Protocol (PPSP) including tracker and peer
 >    signaling components, and discusses the scope, requirements and uses
 >    cases of PPSP.

   s/and uses cases/and use cases/
  Status of this Memo


Section 1., paragraph 1:

 >    Streaming traffic is among the largest and fastest growing traffic on
 >    the Internet [Cisco], where peer-to-peer (P2P) streaming contribute
 >    substantially. With the advantage of high scalability and fault

   s/streaming contribute/streaming contributes/


Section 1., paragraph 2:

 >    tolerance against single point of failure, P2P streaming applications
 >    are able to distribute large-scale, live and video on demand (VoD)
 >    streaming programs to millions of audience with only a handful of

   "millions of audience" doesn't sound right. How about "to a large
   audience"?


Section 1., paragraph 3:

 >    servers. What's more, along with the new players like CDN providers

   CDN providers are not really new players in the content distribution
   market anymore. They are in the market much longer than p2p...


Section 1., paragraph 5:

 >    Given the increasing integration of P2P streaming into the global
 >    content delivery infrastructure, the lack of an open, standard P2P
 >    streaming signaling protocol suite becomes a major missing component
 >    in the protocol stack. Almost all of existing systems use their

   just delete "in the protocol stack", as it does not add to the
   sentence, but it add confusion.


Section 1., paragraph 7:

 >    In this document we propose an open P2P Streaming Protocol, which is
 >    defined as PPSP, to standardize signaling operations in P2P streaming

   s/defined as PPSP/abbreviated as PPSP/.


Section 2., paragraph 7:

 >    Peer: A peer refers to a participant in a P2P streaming system that
 >    not only receives streaming content, but also stores and streams
 >    streaming content to other participants.

   A peer does not need to store content.


Section 2., paragraph 11:

 >    Tracker: A tracker refers to a directory server that maintains a list

   Wouldn't it be better to say 'directory service' instead of
   'directory server'? Below you say that the tracker is a logical
   entity that can be centralized (indeed a server ) or distributed
   (not a server). Service would match better here.


Section 2., paragraph 13:

 >    Video-on-demand (VoD): It refers to a scenario where different
 >    clients may watch different parts of the same recorded media with
 >    downloaded content.

   You use sometimes media and sometimes content. Choose one and stick
   to it throughout the whole draft.


Section 3.1., paragraph 1:

 >    ISPs are faced to different P2P streaming application introducing

   s/are faced to/are faced with/


Section 3.1., paragraph 3:

 >    However, unlike Web traffic that is represented by HTTP packets and

   s/HTTP packets/HTTP requests/repsonses/
  'HTTP packets' isn't the right term.


Section 3.2., paragraph 2:

 >    In the Hybrid CDN/P2P approach, the CDN takes two roles: media
 >    streaming server and P2P tracker. Similarly to what described in

   s/to what described /to what is described/


Section 3.2., paragraph 3:

 >    section 3.1, proprietary P2P protocols introduce complexity between
 >    peers and CDN trackers because the CDN trackers need to identify each
 >    different P2P streaming protocol. This increases the deployment cost
 >    of CDN.

   I do not understand the issue here. First of all, all the different
   p2p streaming systems could use a common tracker protocol. Second,
   how does the above text relate to latency issues? Third, even if
   there are multiple, different tracker protocols what is this related
   to in this section?


Section 3.3., paragraph 3:

 >    However it's difficult to apply current P2P streaming protocols (even
 >    assuming we can re-use some of the proprietary ones) in mobile and
 >    wireless networks. Although smart handsets are more eligible to
 >    become peers with much higher bandwidth, CPU frequency, larger
 >    storage and memory than before, peer selection will become more
 >    challenging due to the increase and complexity of exchange between
 >    peers and trackers. Current P2P protocols are not well suited for
 >    these new requirements in the context of mobile and wireless
 >    networks.

   I do know what you are targetting at, but I cannot understand it
   from the above text. The interactions between mobile terminals and
   trackers are not different to fixed terminals and trackers. The
   issue is more that p2p assumes a stable Internet connection in
   downlink and uplink direction, with decent capacity and peers
   that can run for hours. This isn't the typical setting for mobile
   terminals. Your examples should some of the challenges but the text
   above is confusing at best.


Section 3.3., paragraph 5:

 >    Second, current practices often use a "bitmap" message in order to
 >    exchange chunk availability. The message is of kilobytes in size and
 >    exchanged frequently, for example, several seconds. In a mobile

   'several seconds' isn't correct here. You probably mean 'several
   times in a second'.


Section 4., paragraph 0:

 >    Third, for a resource constraint peer like mobile handsets or set-top
 >    boxes (STB), there are severe contentions on limited resource when
 >    using proprietary protocols. The peer has to install many different
 >    streaming applications for different usages, e.g., some for movies
 >    and others for sports and each of these applications will compete for
 >    the same set of memories, flashes or hard disks(some may run in the
 >    background even they are not invoked by the users). Open protocols 
creat
 >    an opportunity to use one client software accommodating different 
P2P systems.
 >    This may alleviate this problem.

   What 'may alleviate this problem'?
  4. PPSP: Standard peer to peer streaming protocols


Section 4., paragraph 1:

 >    PPSP is targeted to standardize signaling protocols for tracker-based
 >    architectures to solve the above problems that support either live or
 >    VoD streaming.

   I do not think that the above statement is compeletly right, as the
   peer protocol, as I know it, can operate with tracker based systems,
   but also without a tracker.


Section 4.1., paragraph 0:

  4.1. Tracker protocol candidates discussion and design issues

   Why is there the need to discuss the candidates in this
   draft? Wouldn't it be better to roughly sketch the task of the
   tracker protocol? I.e., to give a reasoning why it is required?


Section 4.1., paragraph 1:

 >    Tracker protocol: The tracker protocol is best modeled as a
 >    request/response protocol between peers and trackers, and will carry

   Remove the first part of the sentence, i.e., 'Tracker protocol:'.

 >    information needed for the selection of peers suitable for real-
 >    time/VoD streaming.


Section 4.1., paragraph 5:

 >    PPSP tracker protocol will select the best of the above options

   This sentence is not correct, as the tracker will not select any
   option, but the WG will select something, isn't it?


Section 4.2., paragraph 0:

  4.2. Peer protocol candidates discussion and design issues

   Why is there the need to discuss the candidates in this
   draft? Wouldn't it be better to roughly sketch the task of the peer
   protocol? I.e., to give a reasoning why it is required?


Section 4.2., paragraph 1:

 >    Peer Protocol: The peer protocol is modeled as a gossip-like protocol
 >    with periodic exchanges of neighbor and media chunk availability
 >    information. Namely, the peer protocol is a content-centric protocol
 >    built around the abstraction of a cloud of participants disseminating
 >    the same data in ways and orders that are convenient to the
 >    participants [I-D.ietf-ppsp-peer-protocol]. In that respect and in
 >    light of the above requirements, typical HTTP is neither suitable nor
 >    efficient.

   what does this paragraph add to the discussion?


Section 4.2., paragraph 5:

 >    The PPSP peer protocol will discuss the protocol design rationales in
 >    detail.

   This section does not help in terms of problem statement nor for
   the requirements listed later on. It would be much better to explain
   briefly what the peer protocol is expected to do and how the earlier
   mentioned problems are addressed by a standardized peer protocol.


Section 5.1., paragraph 1:

 >    The content provider can efficiently increase live streaming coverage
 >    by introducing PPSP in between different providers.

   'in' or 'between' or 'in-between'?


Section 5.1., paragraph 2:

 >    Figure 2 shows the case of provider A broadcasting a TV program with
 >    the help of provider B and C for a wider coverage by introducing PPSP.
 >    Without PPSP, when users outside A requests TV program@A, the
 >    returned peer-list may include few local peers. This may affect the
 >    user experience. With PPSP, B and C can involve in the broadcasting.

   Honestly, I do not understand the case you are describing. Neither
   the text nor the figure help me in explaining what it is about.


Section 5.1., paragraph 3:

 >    The providers often deploy in-network peers called super-nodes (SN

   'Super-node' is not mentioned in the terminology.


Section 5.1., paragraph 5:

 >    Figure 3 shows the case of cooperative VoD provision by introducing
 >    PPSP inside CDN overlays and in between different CDNs. It is similar
 >    to Figure 2 except that the intermediate SNs are replaced by 3rd
 >    party CDN surrogates. The CDN nodes talk with the different streaming
 >    systems with the same PPSP protocols. Note that for compatibility
 >    reason both HTTP streaming and P2P streaming can be supported by CDN.

   I would suggest to move the hybrid cdn/p2p case in a new section
   and not to be part of section 5.1


Section 5.3., paragraph 1:

 >    In Figure 5, when peers request the P2P streaming data, the cache
 >    nodes intercept the requests and ask for the frequently visited
 >    content (or part of) on behalf of the peers. To do this, it asks the
 >    tracker for the peer-list and the tracker replies with external peers
 >    in the peer-list. After the cache nodes exchange data with these
 >    peers, it can also act as a peer and report what it caches to the
 >    tracker and serve requesting peers inside afterward. This operation
 >    greatly decreases the inter-network traffic and increases user

   I would add 'can greatly decrease', as in some situations it
   wouldn't. E.g., when each peer is asking for a different content.


Section 6., paragraph 1:

 >    This section enumerates the requirements that should be considered
 >    when designing PPSP.

   The requirements use normative language according RFC 2119. However,
   RFC 2119 is never mentioned in the draft at all.


Section 6.1., paragraph 0:

  6.1. Basic Requirements

   Many of the requirements listed here are not basic requirements
   but already very specific requirements that belong in other
   sections. E.g., the peer ID belongs IMHO into the peer section.


Section 6.1., paragraph 1:

 >    PPSP.REQ-1: The tracker and the peer protocol SHOULD allow peers to
 >    receive streaming content within the required time constraints.

   This not a protocol requirement, as it is not specifying something
   we can qualify later on.


Section 6.1., paragraph 7:

 >    A key characteristic of P2P streaming system is allowing the data
 >    fetching from different peers concurrently. Therefore, the whole
 >    streaming content must allow to be partitioned into small pieces or
 >    chunks for transmission between peers.

   This seems to be more a prerequisite instead of a protocol
   requirement.


Section 6.1., paragraph 10:

 >    PPSP.REQ-6: The tracker protocol and peer protocol are recommended to
 >    be carried over TCP or UDP.

   No 'MUST' or 'SHOULD' like the other requirements? Why is there
   only a single requirements for both protocols, i.e., for the peer
   protocol and the tracker protocol? Shouldn't this at least be 2
   separated requirements?


Section 6.1., paragraph 11:

 >    PPSP.REQ-7: The tracker and peer protocol together MUST facilitate
 >    acceptable QoS (e.g. low startup delay, low channel/content switching
 >    time and minimal end-to-end delay) for both live and VoD streaming
 >    even for very popular content. The tracker and peer protocol do not
 >    include the algorithm required for scalable streaming. However, the
 >    tracker and peer protocol SHALL NOT restrict or place limits on any
 >    such algorithm.

   This requirement is at least listing 2 requirements. Something about
   QoS and the limits of the algorithm. QoS is again hard to qualify
   and if you want to say something about this, I would suggest to
   not make a requirement, but to add explanatory text about this,
   like you have below this.


Section 6.2., paragraph 3:

 >    PPSP.TP.REQ-2: The peer MUST implement the tracker protocol for
 >    sending queries and periodical peer status reports/updates to the
 >    tracker and receiving the corresponding replies.

   How about instead of 'The peer' 'A PPSP peer'? This seems to be
   not a requirement for the tracker (i.e., wrong section), but a
   requirement for a peer.


Section 6.2., paragraph 9:

 >    PPSP.TP.REQ-7: The chunk availability information of the peer SHOULD
 >    be reported to tracker when tracker needs such information to steer
 >    peer selection. The chunk information MUST at least contain the
 >    chunk ID.

   This requirement is misleading, as it does not exactly state what
   the requirement for the tracker protocol is. It could read that
   the tracker protocol should support the reporting of about chunk
   availability.


Section 6.2., paragraph 10:

 >    PPSP.TP.REQ-8: The chunk availability information between peer and
 >    tracker MUST be expressed as compact as possible.

   What is as compact as possible? A 10th of the original size? This
   is not a good requirement.


Section 6.2., paragraph 12:

 >    PPSP.TP.REQ-9: The status of the peer SHOULD be reported to the
 >    tracker when tracker needs such information in order to steer peer
 >    selection.

   This implies that the tracker protocol is not a pure request/response
   protocol from the peer's perspective, isn't it?




-- 
IETF Transport Area Director

[e-mail]

NEC Laboratories Europe - Network Research Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 283