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

Martin Stiemerling <martin.stiemerling@neclab.eu> Fri, 28 September 2012 08:58 UTC

Return-Path: <Martin.Stiemerling@neclab.eu>
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 D26E621F849D for <ppsp@ietfa.amsl.com>; Fri, 28 Sep 2012 01:58:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.813
X-Spam-Level:
X-Spam-Status: No, score=-98.813 tagged_above=-999 required=5 tests=[AWL=-3.509, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, 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 W0oiuQ1+2HSF for <ppsp@ietfa.amsl.com>; Fri, 28 Sep 2012 01:58:29 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id DED7321F8496 for <ppsp@ietf.org>; Fri, 28 Sep 2012 01:58:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 0679D101F9B; Fri, 28 Sep 2012 10:58:27 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9M3sf3ED9agQ; Fri, 28 Sep 2012 10:58:26 +0200 (CEST)
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id DEC97101F95; Fri, 28 Sep 2012 10:58:11 +0200 (CEST)
Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 28 Sep 2012 10:57:48 +0200
Message-ID: <506566A3.3020005@neclab.eu>
Date: Fri, 28 Sep 2012 10:58:11 +0200
From: Martin Stiemerling <martin.stiemerling@neclab.eu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: zhangyunfei <zhangyunfei@chinamobile.com>
References: <505C70EF.6040000@neclab.eu> <2012092411122153407042@chinamobile.com>, <50605EC9.4060507@neclab.eu> <20120925104100729123232@chinamobile.com>
In-Reply-To: <20120925104100729123232@chinamobile.com>
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.1.1.190]
Cc: ppsp <ppsp@ietf.org>
Subject: Re: [ppsp] =?gb2312?b?u9i4tDogUmU6ICBBbiBlYXJseSBBRCByZXZpZXcgb2Yg?= =?gb2312?b?ZHJhZnQtaWV0Zi1wcHNwLXByb2JsZW0tc3RhdGVtZW50LTEwLnR4dA==?=
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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 08:58:30 -0000

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