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

zhangyunfei <zhangyunfei@chinamobile.com> Tue, 25 September 2012 02:41 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 E5FD921F88A3 for <ppsp@ietfa.amsl.com>; Mon, 24 Sep 2012 19:41:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -93.649
X-Spam-Level:
X-Spam-Status: No, score=-93.649 tagged_above=-999 required=5 tests=[AWL=-2.321, 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 OZJPPS-qeCvS for <ppsp@ietfa.amsl.com>; Mon, 24 Sep 2012 19:41:07 -0700 (PDT)
Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF4821F84C5 for <ppsp@ietf.org>; Mon, 24 Sep 2012 19:41:07 -0700 (PDT)
Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 3A0C1E5F8; Tue, 25 Sep 2012 10:41:08 +0800 (CST)
Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 2CF51E5F7; Tue, 25 Sep 2012 10:41:08 +0800 (CST)
Received: from zyf-PC ([10.2.49.171]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012092510410676-10203 ; Tue, 25 Sep 2012 10:41:06 +0800
Date: Tue, 25 Sep 2012 10:41:00 +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>
X-Priority: 3 (Normal)
X-Mailer: Foxmail 7.0.1.85[cn]
Mime-Version: 1.0
Message-ID: <20120925104100729123232@chinamobile.com>
X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-09-25 10:41:06, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-09-25 10:41:08, Serialize complete at 2012-09-25 10:41:08
Content-Type: multipart/alternative; boundary="----=_001_NextPart037678867412_=----"
X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19208.003
X-TM-AS-Result: No--39.501-7.0-31-10
X-imss-scan-details: No--39.501-7.0-31-10;No--39.501-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: Tue, 25 Sep 2012 02:41:10 -0000

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

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