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

[Martin Stiemerling <[e-mail]>]

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:[e-mail]>
> *发送时间：* 2012-09-24 21:23
> *收件人：* zhangyunfei <mailto:[e-mail]>
> *抄送：* ppsp <mailto:[e-mail]>; ZongNing <mailto:[e-mail]>
> *主题：* Re: [ppsp] An early AD review of 
> draft-ietf-ppsp-problem-statement-10.txt
>  > 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.
> [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!

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

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