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

Martin Stiemerling <martin.stiemerling@neclab.eu> Thu, 27 September 2012 06:53 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 DFA9921F86A2 for <ppsp@ietfa.amsl.com>; Wed, 26 Sep 2012 23:53:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.453
X-Spam-Level:
X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, 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 GuirlgjmmAUG for <ppsp@ietfa.amsl.com>; Wed, 26 Sep 2012 23:53:43 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 01FC221F86A3 for <ppsp@ietf.org>; Wed, 26 Sep 2012 23:53:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id E052F101F36; Thu, 27 Sep 2012 08:53:41 +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 FeSu8Qtu9hAv; Thu, 27 Sep 2012 08:53:41 +0200 (CEST)
Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id C4D66101F3C; Thu, 27 Sep 2012 08:53:31 +0200 (CEST)
Received: from [10.7.0.105] (10.7.0.105) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 27 Sep 2012 08:53:31 +0200
Message-ID: <5063DA38.9020705@neclab.eu>
Date: Thu, 27 Sep 2012 06:46:48 +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: Zongning <zongning@huawei.com>
References: <505C70EF.6040000@neclab.eu> <B0D29E0424F2DE47A0B36779EC66677924AE9389@szxeml504-mbs.china.huawei.com>
In-Reply-To: <B0D29E0424F2DE47A0B36779EC66677924AE9389@szxeml504-mbs.china.huawei.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.7.0.105]
Cc: "ppsp@ietf.org" <ppsp@ietf.org>
Subject: Re: [ppsp] An early AD review of draft-ietf-ppsp-problem-statement-10.txt
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: Thu, 27 Sep 2012 06:53:44 -0000

Hi Ning,

Replying only the open issues:

On 09/24/2012 12:54 PM, Zongning wrote:
[...]


>>
>> Section 6.1., paragraph 0:
>>
>>    6.1. Basic Requirements
>>
>>     Many of the requirements listed here are not basic requirements
>>     but already very specific requirements that belong in other
>>     sections. E.g., the peer ID belongs IMHO into the peer section.
>>
>>
>> Section 6.1., paragraph 1:
>>
>>   >    PPSP.REQ-1: The tracker and the peer protocol SHOULD allow peers to
>>   >    receive streaming content within the required time constraints.
>>
>>     This not a protocol requirement, as it is not specifying something
>>     we can qualify later on.
>
> [Ning] There was discuss about if we should include requirements not only to protocols, but also to P2P streaming system. The previous consensus was yes. But anyway I can add clarification later on.

A clarification would help and if you go for such a requirement, I would 
replace the SHOULD by a MUST.

>
>>
>>
>> Section 6.1., paragraph 7:
>>
>>   >    A key characteristic of P2P streaming system is allowing the data
>>   >    fetching from different peers concurrently. Therefore, the whole
>>   >    streaming content must allow to be partitioned into small pieces or
>>   >    chunks for transmission between peers.
>>
>>     This seems to be more a prerequisite instead of a protocol
>>     requirement.
>>
>
> [Ning] Same as above item. I can add clarification.

Ok.

>
>>
>> Section 6.1., paragraph 10:
>>
>>   >    PPSP.REQ-6: The tracker protocol and peer protocol are recommended
>> to
>>   >    be carried over TCP or UDP.
>>
>>     No 'MUST' or 'SHOULD' like the other requirements? Why is there
>>     only a single requirements for both protocols, i.e., for the peer
>>     protocol and the tracker protocol? Shouldn't this at least be 2
>>     separated requirements?
>>
>>
>
> [Ning] I will separate it to two requirements.

Good and take care that you say what of this is MUST/SHOULD/etc.


>
>> Section 6.1., paragraph 11:
>>
>>   >    PPSP.REQ-7: The tracker and peer protocol together MUST facilitate
>>   >    acceptable QoS (e.g. low startup delay, low channel/content switching
>>   >    time and minimal end-to-end delay) for both live and VoD streaming
>>   >    even for very popular content. The tracker and peer protocol do not
>>   >    include the algorithm required for scalable streaming. However, the
>>   >    tracker and peer protocol SHALL NOT restrict or place limits on any
>>   >    such algorithm.
>>
>>     This requirement is at least listing 2 requirements. Something about
>>     QoS and the limits of the algorithm. QoS is again hard to qualify
>>     and if you want to say something about this, I would suggest to
>>     not make a requirement, but to add explanatory text about this,
>>     like you have below this.
>>
>
> [Ning] Again I think this belongs to P2P system requirements. I will add some clarification.

Ok, but I am not sure about the QoS, as this requirement is hard to 
double-check, i.e., what is acceptable. It is good to state this in the 
draft, but I am not sure that this is a technically verifiable 
requirement. It would if you say that the startup delay must be under x 
seconds, etc. However, I do not see how we can set good values here at 
this stage.

>
>>
>> Section 6.2., paragraph 3:
>>
>>   >    PPSP.TP.REQ-2: The peer MUST implement the tracker protocol for
>>   >    sending queries and periodical peer status reports/updates to the
>>   >    tracker and receiving the corresponding replies.
>>
>>     How about instead of 'The peer' 'A PPSP peer'? This seems to be
>>     not a requirement for the tracker (i.e., wrong section), but a
>>     requirement for a peer.
>>
>>
>
> [Ning] This is requirement on the protocol between peer and tracker, which include both peer and tracker (nodes). I can try to re-phrase the sentence to make it more clear.

It is ok, I got confused on this one. I would only suggest to replace 
'The peer' by 'A PPSP peer'.

>
>>
>> Section 6.2., paragraph 12:
>>
>>   >    PPSP.TP.REQ-9: The status of the peer SHOULD be reported to the
>>   >    tracker when tracker needs such information in order to steer peer
>>   >    selection.
>>
>>     This implies that the tracker protocol is not a pure request/response
>>     protocol from the peer's perspective, isn't it?

Any though about this one?

Thanks,

   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