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

From: Martin Stiemerling <[email-masked]>
Date: Fri, 21 Sep 2012 15:51:43 +0200

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

[email-masked]

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

---

From: zhangyunfei <[email-masked]>
Date: Mon, 24 Sep 2012 18:27:56 +0800

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: [email-masked]
Subject: [ppsp] An early AD review of draft-ietf-ppsp-problem-statement-10.txt
Dear all,

[Yunfei] Okay.
  Status of this Memo

[Yunfei] Okay.

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

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

[Yunfei] Okay.

[Yunfei] Okay.

   A peer does not need to store content.
[Yunfei] How about using *caches* to replace* stores*?

[Yunfei]Good proposal.

[Yunfei] Okay.

[Yunfei] Okay.

[Yunfei] Okay.

[Yunfei] Okay.

   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.

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

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

creat
P2P systems.

[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

   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.

   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. 

[Yunfei] Fine.

[Yunfei] You are right.

[Yunfei] Same as the traker protocol.

   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.

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

   'in' or 'between' or 'in-between'?
[Yunfei] I think it's in-between.

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

[Yunfei] I'll add this in the terminology.

[Yunfei] That's fine.

   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.

  6.1. Basic Requirements

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
[email-masked]
https://www.ietf.org/mailman/listinfo/ppsp

---

From: Zongning <[email-masked]>
Date: Mon, 24 Sep 2012 10:54:56 +0000

Hi, Martin,

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Martin Stiemerling
> Sent: Friday, September 21, 2012 9:52 PM
> To: [email-masked]

[Ning] I will add reference in next revision.

>    This not a protocol requirement, as it is not specifying something

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

>    This seems to be more a prerequisite instead of a protocol

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

>    protocol and the tracker protocol? Shouldn't this at least be 2

[Ning] I will separate it to two requirements.

>    like you have below this.

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

>    not a requirement for the tracker (i.e., wrong section), but a

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

>    the tracker protocol should support the reporting of about chunk

[Ning] Agree. Will fix it later.

>    is not a good requirement.

[Ning] Agree. Will fix it later.

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 24 Sep 2012 15:23:21 +0200

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

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

> [Yunfei] How about using *caches* to replace* stores*?

Caches sounds good!

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

> [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!

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

> room consumption. Does this make sense?

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

> [Yunfei] I would delete "for tracker-based architectures" avoiding the 

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.

>    Since we have pointed out the problems current protocols have, in my 
> initial thoughts (maybe I am wrong), I think in this
> 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?

> [Yunfei] Same as the traker protocol.

My same reply as for the tracker protocol.

> make the peer protocol designers better understand the basic principle 

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

> should do and leave the explaination of "how the earlier 
> mentioned problems are addressed by a standardized peer/tracker protocol"

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.

"

> 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

Just add this text and I am fine! :)

> Is it better to say" can greatly decerease in many conditions"?

Yes much better!

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

---

From: zhangyunfei <[email-masked]>
Date: Tue, 25 Sep 2012 10:41:00 +0800

Hi Martin,
    Thanks for the quick response. It's really helpful for us to understand more the IESG thoughts in general from your reply. Just same as you, I just want to confirm with you the open issues left. Thanks again.

BR
Yunfei

zhangyunfei

发件人： Martin Stiemerling
发送时间： 2012-09-24 21:23
收件人： zhangyunfei
抄送： ppsp; ZongNing
主题： Re: [ppsp] An early AD review of draft-ietf-ppsp-problem-statement-10.txt

[Yunfei] Does it make sense that we describe the CDN problem in only one subsection, but in the beginning of this subsection, to clarify that the main purpose of using CDN is to reduce the latency(i.e., accelerate the speed)?After that,
we state the problem is that the CDN must be aware of the specific p2p streaming protocol in order to form the hybrid  p2p+cdn architecture but we don't involve much of the description about the roles, like tracker or peer....Will this look more
clear?

[Yunfei] I like this proposal. Is it better to shorten section 4 moving all the protocol candidates discussion and just leaving the high-level functional descriptions of the tracker and peer protocol( I am not sure if we need some fine granularity description, say, general information in tracker and peer protocol) and move this section after the use cases.

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 27 Sep 2012 06:46:48 +0200

Hi Ning,

Replying only the open issues:

On 09/24/2012 12:54 PM, Zongning wrote:
[...]

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

A clarification would help and if you go for such a requirement, I would 
replace the SHOULD by a MUST.

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

Ok.

> [Ning] I will separate it to two requirements.

Good and take care that you say what of this is MUST/SHOULD/etc.

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

Ok, but I am not sure about the QoS, as this requirement is hard to 
double-check, i.e., what is acceptable. It is good to state this in the 
draft, but I am not sure that this is a technically verifiable 
requirement. It would if you say that the startup delay must be under x 
seconds, etc. However, I do not see how we can set good values here at 
this stage.

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

It is ok, I got confused on this one. I would only suggest to replace 
'The peer' by 'A PPSP peer'.

>>     protocol from the peer's perspective, isn't it?

Any though about this one?

Thanks,

   Martin

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 28 Sep 2012 10:58:11 +0200

Hello Yunfei,

On 09/25/2012 04:41 AM, zhangyunfei wrote:
> Hi Martin,
>      Thanks for the quick response. It's really helpful for us to 
> understand more the IESG thoughts in general from your reply. Just same 
> as you, I just want to confirm with you the open issues left. Thanks again.
> BR
> Yunfei
> ------------------------------------------------------------------------
> zhangyunfei
> *发件人：* Martin Stiemerling <mailto:[email-masked]>
> *发送时间：* 2012-09-24 21:23
> *收件人：* zhangyunfei <mailto:[email-masked]>
> *抄送：* ppsp <mailto:[email-masked]>; ZongNing <mailto:[email-masked]>
> *主题：* Re: [ppsp] An early AD review of 
> draft-ietf-ppsp-problem-statement-10.txt
> [Yunfei] Does it make sense that we describe the CDN problem in only one 
> subsection, but in the beginning of this subsection, to clarify that the 
> main purpose of using CDN is to reduce the latency(i.e., accelerate the 
> speed)?After that,
> we state the problem is that 
> the CDN must be aware of the specific p2p streaming protocol in order to form the hybrid 
> p2p+cdn architecture but we don't involve much of the description about 
> the roles, like tracker or peer....Will this look more
> clear?

This is a good proposal!

> [Yunfei] I like this proposal. Is it better to shorten section 4 moving 
> all the protocol candidates discussion and just leaving the high-level 
> functional descriptions of the tracker and peer protocol( I am not sure 
> if we need some fine granularity description, say, general information 
> in tracker and peer protocol) and move this section after the use cases.

high-level description should do the job here in this draft.

Regards,

  Martin

---

From: zhangyunfei <[email-masked]>
Date: Fri, 28 Sep 2012 17:15:52 +0800

Thanks Martin. I'll update the text according to your suggestions.

BR
Yunfei

zhangyunfei

发件人： Martin Stiemerling
发送时间： 2012-09-28 16:58
收件人： zhangyunfei
抄送： ppsp; ZongNing
主题： Re:回复: Re: [ppsp] An early AD review of draft-ietf-ppsp-problem-statement-10.txt
Hello Yunfei,

This is a good proposal!

Regards,

  Martin