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

Arno Bakker <> Wed, 27 February 2013 14:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7788921F8496 for <>; Wed, 27 Feb 2013 06:08:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.254
X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MLyQFweAkkIQ for <>; Wed, 27 Feb 2013 06:08:11 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7B60821F8738 for <>; Wed, 27 Feb 2013 06:08:11 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 27 Feb 2013 15:08:08 +0100
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id; Wed, 27 Feb 2013 15:08:08 +0100
Message-ID: <>
Date: Wed, 27 Feb 2013 15:08:35 +0100
From: Arno Bakker <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: []
Subject: Re: [ppsp] New Version Notification for draft-ietf-ppsp-problem-statement-13.txt
X-Mailman-Version: 2.1.12
Precedence: list
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: Wed, 27 Feb 2013 14:08:15 -0000

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