Re: [ppsp] New Version Notification for draft-ietf-ppsp-problem-statement-13.txt

zhangyunfei <> Fri, 08 March 2013 06:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D3E6B21F855A for <>; Thu, 7 Mar 2013 22:21:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -98.623
X-Spam-Status: No, score=-98.623 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z4VAdNPqoZtQ for <>; Thu, 7 Mar 2013 22:21:48 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 083DD21F8540 for <>; Thu, 7 Mar 2013 22:21:46 -0800 (PST)
Received: from (unknown[]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee25139835de72-70e72; Fri, 08 Mar 2013 14:21:17 +0800 (CST)
X-RM-TRANSID: 2ee25139835de72-70e72
Received: from zyf-PC (unknown[]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee3513983596fd-ee40f; Fri, 08 Mar 2013 14:21:16 +0800 (CST)
X-RM-TRANSID: 2ee3513983596fd-ee40f
Date: Fri, 8 Mar 2013 14:21:25 +0800
From: zhangyunfei <>
To: "" <>, ppsp <>
References: <> <>, <>
X-Priority: 3
X-Mailer: Foxmail[cn]
Mime-Version: 1.0
Message-ID: <>
Content-Type: multipart/alternative; boundary="----=_001_NextPart648082581085_=----"
Subject: Re: [ppsp] New Version Notification for draft-ietf-ppsp-problem-statement-13.txt
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: zhangyunfei <>
List-Id: discussing to draw up peer to peer streaming protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Mar 2013 06:21:51 -0000

Hi Arno and all, (Speaking as the co-author)
    Thanks for the comments and Ning will update the requirements part in next week.



From: Arno Bakker
Date: 2013-02-27 22:08
Subject: Re: [ppsp] New Version Notification for draft-ietf-ppsp-problem-statement-13.txt
On 26/02/2013 16:31, stefano previdi wrote:
> Please, have a look at the draft:
> and come back to the list with any comment.

Hi all

I have the following comments:

* PPSP.OAM.REQ-1: PPSP MUST be sufficiently configurable for 
installation and initial setup.

I don't get the reference to "initial setup" there. I suggest
to make the requirement "sufficiently configurable" (which is  
what we strived for with different chunk addressing, content
protection methods) and state that the configuration should
allow the proxy-based and end-client scenarios.

* PPSP.OAM.REQ-2: PPSP MUST implement a set of configuration 
parameters with default values.

IMHO the descriptive text doesn't add anything and suggest it
be removed.

* PPSP.OAM.REQ-3: PPSP MUST be capable of controlling traffic load to
existing networks.

I suggest to rephrase this to "PPSP SHOULD allow steering by
network-load management protocols." Current phrasing I find
unclear and very restrictive with the MUST clause.

* PPSP.OAM.REQ-4: PPSP MUST support diagnostic operations.

Typo: "correct operations" -> "correct operation"
Typo: "*The* PPSP tracker should"
Rephrase: "obtained chunks in due time" -> "whether it obtained
chunks in time".

* PPSP.OAM.REQ-5: PPSP MUST facilitate achieving quality acceptable to
streaming application.

I have problems with the last paragraph about scalable
streaming. To me, it suggests scalable streaming should be
supported. I suggest to rephrase to "PPSP implementations MAY
use techniques such as scalable streaming to handle bandwidth
shortages without disrupting playback."
Typo: "to streaming application" -> "to *the* streaming ..." 
* PPSP.OAM.REQ-6: PPSP MUST support remote management using
centralized server, i.e. PPSP tracker. A basic set of management
information MUST be implemented by PPSP tracker.

The wording suggests a centralized design where all management
operations are done via the tracker. This image is not correct
IMHO. A tracker service can play an important role in managing
a swarm. E.g. it can be used to control publication of a swarm,
or to monitor the health of the swarm. Hence it should have a
standard management interface that supports such functionality.
This interface should take into account that the tracker
*service* may be implemented by multiple *servers*. However,
PPSP should also support tracker-less designs and should define
a management interface for (farms of) PPSP seeders.

I suggest to rephrase the requirement so that the tracker
service and PPSP seeders should have a remote management
interface. Current descriptive text should be tweaked to
explain the unique position of the tracker (sees both clients
and PPSP seeders).

* PPSP.OAM.REQ-9: PPSP MUST support accounting management when content
provider wants to charge clients for certain content.

I suggest to change the "MUST" to a "MAY" or "SHOULD allow
accounting management".


ppsp mailing list