Subject: [ppsp] Comments on peer protocol

From: zhangyunfei <[email-masked]>
Date: Wed, 7 Mar 2012 18:36:28 +0800

Here is my personal comments on peer protocol for today's discussion:
1)bin numbering: How to apply in existing p2p streaming systems? All of them( to the best of my knowledge) use a same level( instead of hierarchical) number to denote the chunkID (and scope); 
2) Merkle hash tree: The way is good for checking content integrity. However is it using too much effort to prevent malicious attacks?( It's different from file downloading case, where the user can detect receiving the wrong file only after it downloads all chunks or using the merkle hash tree detection. But for the "click and play right now" streaming, the user can discern the attack much earlier, right?
3)PEX message reuse in tracker protocol: Should be discussed in tracker protocol protocol or separate proposal;
4) Signaling and data coupling: Obviously there are argument on this point. Should give more evidence on the advantages;
5) Requirement: Should be merged in PS draft?

BR
Yunfei  

zhangyunfei

---

From: Arno Bakker <[email-masked]>
Date: Fri, 9 Mar 2012 16:34:32 +0100

Hi all

On 07/03/2012 11:36, zhangyunfei wrote:
> 1)bin numbering: How to apply in existing p2p streaming systems? All of
> them( to the best of my knowledge) use a same level( instead of
> hierarchical) number to denote the chunkID (and scope);

For systems that use a linear byte address space for assets, these
can be directly mapped to bins, as the lowest bin layer just represents 
that linear address space. Conversely, any bin directly translates to an 
interval in that linear address space, so conversion is easy.

> 2) Merkle hash tree: The way is good for checking content integrity.
> However is it using too much effort to prevent malicious attacks?( It's
> different from file downloading case, where the user can detect
> receiving the wrong file only after it downloads all chunks or using the
> merkle hash tree detection. But for the "click and play right now"
> streaming, the user can discern the attack much earlier, right?

I'm not quite sure I understand the issue, but yes, in a benign 
environment you could turn content-integrity checking off. However,
imagine a speech by president Obama being broadcast via PPSPP and 
hackers replacing it with other content.

> protocol protocol or separate proposal;

IMHO, they are discussed in the right place as the PEX_* messages are 
for decentralized tracking and are between peers.

> 4) Signaling and data coupling: Obviously there are argument on this
> point. Should give more evidence on the advantages;

With coupling, the system requires just one socket per peer. With a 
single socket, you also need to run NAT/firewall traversal and 
authentication procedures only once. Furthermore, it makes the 
implementation simpler. For example, the content-integrity information 
can be transmitted with the chunk.

What would be the advantages of decoupling? And where would we decouple 
data transmission to? There is rough consensus in the working group that 
HTTP is not a suitable protocol for peer-to-peer. That leaves TCP and 
RTP. For TCP, we would have to invent our own transfer protocol that 
supports symmetric retrieval, so then why not do it in one peer protocol 
together with signalling? For RTP, it would be cleaner to add P2P 
signalling, etc. as a profile of RTP, as currently described in Section 
6.3 of the WG item. Whether the bundling with RTP makes sense is still 
an open issue (http://trac.tools.ietf.org/wg/ppsp/trac/ticket/24) that 
we need to discuss.

> 5) Requirement: Should be merged in PS draft?

I imagine that any text on meeting the requirements will be removed from 
the WG item once we agree that they have been met, right?

Have a nice weekend,
     Arno