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

zhangyunfei <zhangyunfei@chinamobile.com> Fri, 28 September 2012 09:17 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 3CF2321F8516 for <ppsp@ietfa.amsl.com>; Fri, 28 Sep 2012 02:17:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -93.262
X-Spam-Level:
X-Spam-Status: No, score=-93.262 tagged_above=-999 required=5 tests=[AWL=-1.934, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222, SARE_SUB_ENC_GB2312=1.345, 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 Hrpz2L2OG60x for <ppsp@ietfa.amsl.com>; Fri, 28 Sep 2012 02:17:01 -0700 (PDT)
Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B9B2C21F84F3 for <ppsp@ietf.org>; Fri, 28 Sep 2012 02:17:00 -0700 (PDT)
Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 8D80DE4A5; Fri, 28 Sep 2012 17:16:54 +0800 (CST)
Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 9CF2CE6E0; Fri, 28 Sep 2012 17:16:05 +0800 (CST)
Received: from zyf-PC ([10.2.52.192]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012092817160366-20842 ; Fri, 28 Sep 2012 17:16:03 +0800
Date: Fri, 28 Sep 2012 17:15:52 +0800
From: zhangyunfei <zhangyunfei@chinamobile.com>
To: "Martin Stiemerling" <martin.stiemerling@neclab.eu>
References: <505C70EF.6040000@neclab.eu> <2012092411122153407042@chinamobile.com>, <50605EC9.4060507@neclab.eu> <20120925104100729123232@chinamobile.com>, <506566A3.3020005@neclab.eu>
X-Priority: 3 (Normal)
X-Mailer: Foxmail 7.0.1.85[cn]
Mime-Version: 1.0
Message-ID: <2012092817155199343216@chinamobile.com>
X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-09-28 17:16:03, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-09-28 17:16:05, Serialize complete at 2012-09-28 17:16:05
Content-Type: multipart/alternative; boundary="----=_001_NextPart156252446058_=----"
X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19216.006
X-TM-AS-Result: No--47.250-7.0-31-10
X-imss-scan-details: No--47.250-7.0-31-10;No--47.250-7.0-31-10
X-TM-AS-User-Approved-Sender: No;No
X-TM-AS-User-Blocked-Sender: No;No
Cc: ppsp <ppsp@ietf.org>
Subject: [ppsp] =?gb2312?b?u9i4tDogUmU6ICBBbiBlYXJseSBBRCByZXZpZXcgb2Yg?= =?gb2312?b?ZHJhZnQtaWV0Zi1wcHNwLXByb2JsZW0tc3RhdGVtZW50LTEwLnR4?= =?gb2312?b?dA==?=
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: Fri, 28 Sep 2012 09:17:02 -0000

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,

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:martin.stiemerling@neclab.eu>
> *发送时间:* 2012-09-24 21:23
> *收件人:* zhangyunfei <mailto:zhangyunfei@chinamobile.com>
> *抄送:* ppsp <mailto:ppsp@ietf.org>; ZongNing <mailto:zongning@huawei.com>
> *主题:* 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

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