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

[Martin Stiemerling <[e-mail]>]

Hi Yunfei,

I'm just replying to the open items and I have removed the other items
which are agreed.

On 09/24/2012 12:27 PM, zhangyunfei wrote:
> Hi Martin,
> 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.

The number of users is a million right now, but could 10 million by
tomorrow or 500,000 by tomorrow. Any number in that range is always 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...
> [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.

I think if you write "along with the players like CDN providers joining"
it is better to understand and also clear that they are new, since they
are 'joining'.

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

Caches sounds good!

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

This I can easily understand and it would be good to separate it from
the latency, e.g., making a new paragraph afterwards.


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.

Can you add this text, you just proposed here, of course adapted to the
text flow? This helps a lot to understand the improvement of the latency.

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

I would appreciate this!

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

Yes, please check. I would reword it to 'exchanged frequently, e.g.,
every few seconds' or 'an interval of several seconds'.

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

It makes perferctly sense, I would suggest to add you above text to the
'may alleviate'.

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

Partially agree: I would remove 'or tracker-based architectures' in the
sentence and make a separate one 'PPSP targets tracker-based
architectures, as well as, architectures without tracker'. This is an
important aspect to mention.

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

There can be various opinions about whether such section is useful in
this draft or not. I do not find it useful here, but I do not object to
keep it in, if the WG wants to have it.

I am just wondering, if a high-level text about general functionality of
the tracker protocol is  probably linked to the requirements later on,
would be useful?

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

My same reply as for the tracker 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.

ok, what about replacing 'The peer protocol is modeled' with 'The peer
protocol is expected to be modeled'?

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

I would suggest to remove this part of Section 4.2:
" We list two peer protocol candidates:

   Websockets for bidirectional HTTP: WebSockets is basically a
   bidirectional TCP connection derived from a HTTP connection hence
   allowing a bidirectional P2P transport over HTTP. On the negative
   side, TCP is not ideally suited for multi-party transfers of the same
   content (see Rationale section in I-D.ietf-ppsp-peer-protocol) and
   therefore it introduces implementation (i.e., code) complexity.

   UDP based: Unlike TCP or HTTP, UDP is a datagram-based protocol
   without any sequential data stream abstraction which is, in most the
   cases, unnecessary for PPSP. Compared to the use of TCP, it reduces
   the per-connection footprint and complexity of TCP especially in
   resource constraint mobile cases.

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


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

Just add this text and I am 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"?

Yes much better!

> Section 6., paragraph 1:
> [Yunfei] Ning will reply the requirements part in the following days.

Ok, have seen his reply, though I still have to go through them.

  Martin

[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