[ppsp] 回复: Re: comments on draft-ietf-ppsp-peer-protocol-03.txt

[zhangyunfei <[e-mail]>]

Hi Arno,
    Pls see inline.

BR
yunfei




zhangyunfei

From: Arno Bakker
Date: 2012-11-06 20:43
To: zhangyunfei
CC: ppsp; stefano previdi
Subject: Re: comments on draft-ietf-ppsp-peer-protocol-03.txt
Hi Yunfei et al.

On 02/11/2012 09:29, zhangyunfei wrote:
> Hi Arno (Speaking individually),
> I've read the draft and the following is my comments:
> 1) The effect of "choke/unchoke" is not very clear in the draft. Will
> this increase the transfer efficiency?

The CHOKE/UNCHOKE is a mechanism that deployments/policies on top of the 
base protocol may choose to use. It will make an implementation simpler. 
Imagine you are connected to a good peer (i.e., one that sends DATA 
back). If the good peer sends you a CHOKE, you immediately know that he 
is not going to respond anymore and you should look for a different peer 
to download from. No need to retry REQUESTs.
【Yunfei】I understand this point. My question is based on the fact that peers in p2p streaming 
is of less incentive to be free-riding than file sharing peers. So the effect of CHOKE/UNCHOKE is not 
not clear. 

> 3) Is it better to combine section 5,6, 7 into security consideration
> section as all these 3 sections involve identifying the data is from the
> reliable source/peers, which is related to security more or less. What's
> more, it makes the draft better structured.

I personally see two issues. First, it means content integrity isn't 
discussed before we present the protocol options and UDP encapsulation. 
Second, the Security Considerations section will become roughly 20 pages 
out of a 47 total which sounds a bit unbalanced to me. But you have more 
experience in this than I, so please let me know what is common.
[Yunfei] How about combine section 5.6,7 into a section before currently section 8? To my understanding,
 all the three sections talk about the same problem. Is that correct?

CU,
      Arno