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

[Zongning <[e-mail]>]

Hi, Martin,

Thank you very much for your review. Please see my initial response in Section 6 (requirements).

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Martin Stiemerling
> Sent: Friday, September 21, 2012 9:52 PM
> To: [e-mail]
> Subject: [ppsp] An early AD review of draft-ietf-ppsp-problem-statement-10.txt
> 
> 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.

[Ning] I will add reference in next revision.

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

[Ning] There was discuss about if we should include requirements not only to protocols, but also to P2P streaming system. The previous consensus was yes. But anyway I can add clarification 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.
> 

[Ning] Same as above item. I can add clarification.

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

[Ning] I will separate it to two 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.
> 

[Ning] Again I think this belongs to P2P system requirements. I will add some clarification.

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

[Ning] This is requirement on the protocol between peer and tracker, which include both peer and tracker (nodes). I can try to re-phrase the sentence to make it more clear.

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

[Ning] Agree. Will fix it later.

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

[Ning] Agree. Will fix it later.

> 
> 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
> _______________________________________________
> ppsp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ppsp