Subject: [ppsp] comments on draft-ietf-ppsp-peer-protocol-03.txt

From: zhangyunfei <[email-masked]>
Date: Fri, 2 Nov 2012 16:29:43 +0800

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?
2) I am fine with the update on section 4. It's good to discuss the compatibility issue in chunk addressing.
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.

BR
yunfei

zhangyunfei

From: Arno Bakker
Date: 2012-10-22 15:12
To: zhangyunfei
CC: ppsp; stefano previdi
Subject: Re: [ppsp] I-D Action: draft-ietf-ppsp-peer-protocol-03.txt
On 22/10/2012 09:07, zhangyunfei wrote:
> Hi Arno,
> Would you please summarize the main changes of this version of draft?
> That will be helpful to review the draft. Thanks.

Hi Yunfei et al

there is still a revision history at the back of the document. I will 
update the tickets soon:

    Arno

    -03 2012-10-22 Major revision

        *   Updated Abstract and Introduction, removing download case.

        *   Resolved Ticket #4: Added explicit CHOKE/UNCHOKE messages.

        *   Removed directory lists unused in streaming.

        *   Resolved Ticket #22, #23, #28: Failure behaviour, error codes
            and dealing with peer crashes.

        *   Resolved Ticket #13: Chunk ranges are the default chunk
            addressing scheme that all peers MUST support.

        *   Added a section on compatibility between chunk addressing
            schemes.

        *   Expanded the explanation of Unified Merkle Trees as a method
            for content integrity protection for live streams.

        *   Added a section on forgetting chunks in live streaming.

        *   Added "End" option to protocol options and corrected bugs in
            UDP encapsulation, following Karl Knutsson's comments.

        *   Added SHA-2 support for Merkle Hash functions.

        *   Added content integrity protection methods for live streaming
            to the relevant protocol option.

        *   Added a Live Signature Algorithm protocol option.

        *   Resolved Ticket #24+27: The choice for UDP + LEDBAT as
            transport has now been reflected in the draft.  TCP and RTP
            encapsulations have been removed.

        *   Superfluous parts of Section 10 on extensibility have been
            removed.

        *   Removed appendix with Rationale.

        *   Resolved Ticket #21+25: PPSPP currently uses LEDBAT and the
            DATA and ACK messages now contain the time fields it
            requires.  Should other congestion control algorithms be
            supported in the future, a protocol option will be added.

---

From: Arno Bakker <[email-masked]>
Date: Tue, 6 Nov 2012 13:43:02 +0100

Hi Yunfei et al.

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

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

CU,
      Arno

---

From: zhangyunfei <[email-masked]>
Date: Fri, 9 Nov 2012 14:06:47 +0800

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.

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. 

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

---

From: zhangyunfei <[email-masked]>
Date: Wed, 21 Nov 2012 15:34:13 +0800

Hi Arno,
     Sorry that I made a mistake not  cc-ing  to ppsp mailing list. Please see inline for the reply.

BR
Yunfei

zhangyunfei

From: Arno Bakker
Date: 2012-11-21 15:18
To: zhangyunfei
Subject: Re: comments on draft-ietf-ppsp-peer-protocol-03.txt
On 16/11/2012 10:25, zhangyunfei wrote:
> See inline.

Hi Yunfei

I'm sure you noticed that this mail didn't go to the mailing list?

> [Yunfei] My feeling is as follows: P2P stremaing, in contrast to p2p
> file downloading,
> need more stable and longer connections with some (may few) peers for
> video quality assurance.
> That is to say, a streaming peer has less chance to be selflish (not
> contribute) in order to
> get data from other peers( or else, other peers can easily detect the
> behavior and can kick it out of
> the swarm). Is that right?

You are right that for live streaming there is more risk in cheating.
For video-on-demand it is more complex. Whether people will cheat or not 
depends rationally on whether there is sufficient capacity, IMHO. If you 
get cut off by one peer that is not a problem if there is another one 
that you can leech from. There is no secure or efficient way of 
distributing info about bad peers to others, so as long as there are 
victims, you can continue freeriding.

[Yunfei] I am okay to add CHOKE/UNCHOKE in peer protocol.

> I think 6 (Merkle tree + auto size) can be made a subsection of 5
> (content integrity). I'd like to keep 7 (Live Streaming) as a separate
> section as it discusses more than integrity protection, in particular,
> forgetting chunks to achieve efficient infinite streams.
> [Yunfei] Sorry but can you say more on the last sentence?I am not sure I
> get your point.

Section 7 is about live streaming in general, not just content 
protection. Hence I don't want to merge it into the content integrity 
section. In particular, Section 7 talks about how peers communicate that 
they are discarding chunks from the past such that their disk doesn't 
fill up on long broadcasts.

[Yunfei] I would suggest then merge the content integrity check part in live streaming
into "content integrity" section and leave other part in live streaming another section.

Hope this helps. Feel free to crosspost this to the mailing list.

CU,
     Arno