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

zhangyunfei <zhangyunfei@chinamobile.com> Mon, 24 September 2012 10:28 UTC

Return-Path: <zhangyunfei@chinamobile.com>
X-Original-To: ppsp@ietfa.amsl.com
Delivered-To: ppsp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D4321F8487 for <ppsp@ietfa.amsl.com>; Mon, 24 Sep 2012 03:28:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -95.646
X-Spam-Level:
X-Spam-Status: No, score=-95.646 tagged_above=-999 required=5 tests=[AWL=-0.538, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GprUsLHwj662 for <ppsp@ietfa.amsl.com>; Mon, 24 Sep 2012 03:28:05 -0700 (PDT)
Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id DE14B21F8464 for <ppsp@ietf.org>; Mon, 24 Sep 2012 03:28:03 -0700 (PDT)
Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 3D933E512; Mon, 24 Sep 2012 18:28:03 +0800 (CST)
Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 1A400E40A; Mon, 24 Sep 2012 18:28:03 +0800 (CST)
Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012092418275993-25620 ; Mon, 24 Sep 2012 18:27:59 +0800
Date: Mon, 24 Sep 2012 18:27:56 +0800
From: zhangyunfei <zhangyunfei@chinamobile.com>
To: "Martin Stiemerling" <martin.stiemerling@neclab.eu>, ppsp <ppsp@ietf.org>
References: <505C70EF.6040000@neclab.eu>
X-Priority: 3 (Normal)
X-Mailer: Foxmail 7.0.1.85[cn]
Mime-Version: 1.0
Message-ID: <2012092411122153407042@chinamobile.com>
X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-09-24 18:27:59, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-09-24 18:28:02
Content-Type: multipart/alternative; boundary="----=_001_NextPart605386236211_=----"
X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19206.006
X-TM-AS-Result: No--37.502-7.0-31-10
X-imss-scan-details: No--37.502-7.0-31-10;No--37.502-7.0-31-10
X-TM-AS-User-Approved-Sender: No;No
X-TM-AS-User-Blocked-Sender: No;No
Subject: Re: [ppsp] An early AD review of draft-ietf-ppsp-problem-statement-10.txt
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: zhangyunfei <zhangyunfei@chinamobile.com>
List-Id: discussing to draw up peer to peer streaming protocol <ppsp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ppsp>, <mailto:ppsp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ppsp>
List-Post: <mailto:ppsp@ietf.org>
List-Help: <mailto:ppsp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ppsp>, <mailto:ppsp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Sep 2012 10:28:07 -0000

Hi Martin,
    First of all, thanks so much for your valuable comments, suggestions and questions on the draft. Here are some initial response. Further comments, esp. for section 4 are high appreciated. Thanks.

BR
yunfei 




zhangyunfei

From: Martin Stiemerling
Date: 2012-09-21 21:51
To: ppsp@ietf.org
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/

[Yunfei] Okay.
  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/

[Yunfei] Okay.

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"?
[Yunfei] Actually there are reports on some measurements paper to show PPLive has more than 1 million concurrent users .  But I am fine on your suggestion.

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

[Yunfei] Let me clarify my point. Here I mean the new players on *p2p streaming
delivery*, instead of common content delivery. We know that Akamai supported
p2p streaming much later than the p2p streaming providers.
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.
[Yunfei] Okay.

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/.
[Yunfei] Okay.

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.
[Yunfei] How about using *caches* to replace* stores*?


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.

[Yunfei]Good proposal.


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.
[Yunfei] Okay.

Section 3.1., paragraph 1:

 >    ISPs are faced to different P2P streaming application introducing

   s/are faced to/are faced with/
[Yunfei] Okay.


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.
[Yunfei] Okay.

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/

[Yunfei] Okay.
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?
[Yunfei] What I mean is that *before* we design and implement PPSP, different P2P streaming
systems have to use different protocols. Second, for the latency issue, it is because the introduction of *CDN* nodes 
inside the p2p streaming delivery reduce the latency (see in the reference in the text for detail). The problem is that the CDN must be aware of the specific p2p streaming protocol in order to form the hybrid p2p+cdn architecture, which can lead to a shorter latency from the users' perspective.



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.
[Yunfei] I totally agree with your judgement on the mobile terminal problems, basically as identified in next paragraph. If people think this paragraph is confusing in text, I would propose to move most of the confused text.

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'.
[Yunfei]*'Several seconds* is the condition in some practical p2p streaming systems. I will check the
current practice to see if it is more frequent than before.

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

[Yunfei] The basic idea is that the "one client software+different scheduling plug-ins"
is better than "different client softwares running at the same time" in memory and disk
room consumption. Does this make sense?
  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.
[Yunfei] I would delete "for tracker-based architectures" avoiding the confusion.

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?
[Yunfei] My intention to discuss the candidates in this
   draft is to reply David Harrington's IESG review on the tasks of the tracker protocol, as you also mentioned.
  Since we have pointed out the problems current protocols have, in my initial thoughts (maybe I am wrong), I think in this
section we may need the discuss the candidates of the protocols, since the protocol design is the main tasks of 
the WG. May I further ask your imaginations on the content of this part in detail? It would be much helpful for writing this part. 

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

[Yunfei] Fine.

 >    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?
[Yunfei] You are right.

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?

[Yunfei] Same as the traker protocol.
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?
[Yunfei] The intention to add this description on the peer protocol is to 
make the peer protocol designers better understand the basic principle of the peer protocol.
More detailed comments are appreciated.

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.

[Yunfei] Actually we want to explain in this section what the peer and tracker protocol 
should do and leave the explaination of "how the earlier mentioned problems are addressed by a standardized peer/tracker protocol"
in section 5, the use cases section. But we may not fulfil the former task perfectly now.
I guess we may add some desciptions on, e.g., the information flows and related
parameters in the two protocols in a high-level? To be honest, we are not sure about 
what the specific content we need to write. So the detailed guidance is highly helpful.


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'?
[Yunfei] I think it's 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.

[Yunfei] The basic idea is that considering there is only  A(e.g,, in China) providing the live streaming
in provider B(e.g., in USA) and C(e.g., in Europe)'s coverage. When a user(e.g.,a chinese american) in USA requests the program to the tracker( it is located in A's coverage), the tracker can return to the user with a peer-list including most of peers in China(Because generally most users are in China and there are only few users in USA). But if we can use PPSP to 
involve B and C in the provision, even when the streaming is not hot to attract many users in USA and Europe to view, the 
tracker in A can return the user with a peer-list including B's SN and C's SN. 


Section 5.1., paragraph 3:

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

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

[Yunfei] I'll add this 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

[Yunfei] That's fine.


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.
[Yunfei] The hit ratio of p2p cache in practical networks is about 90%+ in statistics.
Is it better to say" can greatly decerease in many conditions"?


Section 6., paragraph 1:
[Yunfei] Ning will reply the requirements part in the following days.
 >    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

martin.stiemerling@neclab.eu

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
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp