Subject: [ppsp] Proposal to resolve Issue 10 + 13

From: Arno Bakker <[email-masked]>
Date: Wed, 18 Jan 2012 11:41:51 +0100

Hi all

in this mail I propose a solution to the following issues:

10. Need to allow for multiple content-integrity protection schemes for
live video. [Picconi]  (and video-on-demand)

13. Allow for multiple content addressing schemes, explain dependencies
of other swift features on bin addressing. [Kiraly,Zhang]

Proposal:
=========

The (meta)data required for the Peer-to-Peer Streaming Peer Protocol 
(PPSPP) to download and share a piece of content is extended. In 
addition to a swarm ID and a source of peer addresses, a downloader 
needs to known the chunk addressing and content integrity protection 
schemes used. This information can e.g. be encoded in a PPSPP URL and is 
assumed to come from a trusted source.

Rationale: in PPSPP peers are untrustworthy, so these extra protocol 
options cannot be learnt from a sender as in a client/server protocol.

Content Addressing
------------------
The HAVE, ACK, HINT and DATA messages are then defined to carry a chunk 
specification instead of a bin. A chunk specification identifies one or 
more chunks, following the chunk addressing scheme indicated in the 
PPSPP metadata. Chunk addressing schemes could also add metadata about 
the chunks in the chunk specification (cf. Issue 18)

Content Integrity Protection
----------------------------
Initially, there is one content-integrity protection scheme defined,
the Merkle hash trees. This scheme introduces the HASH messages for 
carrying the information needed to verify the integrity of a received 
chunk. When this scheme is used, the swarm ID is the root hash of the 
Merkle hash tree for video-on-demand.

The HASH message contains a node specification and a Modification 
Detection Code (hash). A node specification identifies a node in the 
Merkle hash tree. Ideally, the node addressing scheme used is compatible 
with the chunk addressing scheme, as the former also needs to address 
leaf nodes which correspond to chunks. The bin numbering scheme is 
compatible and can address both nodes and chunks.

Implementations of PPSPP SHOULD implement bin numbers and Merkle hash trees.

What's your opinion?
      Arno

---

From: Picconi Fabio <[email-masked]>
Date: Thu, 19 Jan 2012 15:12:17 +0100

Hi, and happy new 2012!

The Content Addressing part looks good.

As for the Content Integrity part, in the HINT message I would rather use a "chunk specification" instead of a "node specification", to make it generic and thus consistent with the Content Addressing data types.

I'm fine with "SHOULD implement bin numbers" to support a base integrity mechanism.

This defines the messages and data types. The question that remains is *when* the HASH messages must be transmitted, as this may depend on the specific integrity mechanism.

Fabio

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Arno Bakker
Sent: mercredi 18 janvier 2012 11:42
To: ppsp
Subject: [ppsp] Proposal to resolve Issue 10 + 13

Hi all

Proposal:
=========

Content Addressing
------------------

What's your opinion?
      Arno
_______________________________________________
ppsp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ppsp

---

From: zhangyunfei <[email-masked]>
Date: Thu, 19 Jan 2012 22:17:25 +0800

[Speaking individually]
Hi Arno,
     I think the content addressing proposal is reasonable to allow for multiple schemes. 
     Regarding content integrity proposal, I am a little bit confused: Is that saying that Merkle tree solution is a mandatory scheme in content integrity scheme? I am not favoring of this if this were the case. After all, there are many other schemes used in practice. We are hard to determine that merkle tree is mandatory.
    For the same reason, I would suggest to say that "implementations of PPSPP MAY implement bin numbers and Merkle hash trees". Is this making sense?

BR
Yunfei

zhangyunfei

From: Arno Bakker
Date: 2012-01-18 18:41
To: ppsp

Proposal:
=========

Content Addressing
------------------

What's your opinion?
      Arno

---

From: Arno Bakker <[email-masked]>
Date: Mon, 23 Jan 2012 09:50:58 +0100

On 19/01/2012 15:12, Picconi Fabio wrote:
> As for the Content Integrity part, in the HINT message I would rather
> use a "chunk specification" instead of a "node specification", to
> make it generic and thus consistent with the Content Addressing data
> types.
>

Hi

I used a different name to convey that the chunk addressing needs "room" 
for node IDs if Merkle trees are used. So you propose not to use this 
textual trick, and just write down the requirement?

> This defines the messages and data types. The question that remains
> is *when* the HASH messages must be transmitted, as this may depend
> on the specific integrity mechanism.
>

What do you mean exactly? The idea is that the HASH message is tied to 
the Merkle hash trees, so if you chose that scheme you'll have HASH 
messages. Or do you want to have a generic HASH message that can also be 
used by other integrity protection schemes?

CU,
     Arno

---

From: Arno Bakker <[email-masked]>
Date: Mon, 23 Jan 2012 10:03:14 +0100

On 19/01/2012 15:17, zhangyunfei wrote:
> Regarding content integrity proposal, I am a little bit confused: Is 
> that saying that Merkle tree solution is a mandatory scheme in content 
> integrity scheme? 

Hi Yunfei

yes, in the sense of the SHOULD definition from RFC 2119: "there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course."

Merkle hash trees enable low latency when used with UDP. Using UDP means
you want to use small chunk sizes such that a chunk fits in an Ethernet
frame to reduce the chance of packet loss. This means you'll have lots
of chunks and therefore lots of hashes. With Merkle hash trees you don't
need to download all hashes beforehand, as in BitTorrent (all hashes in
.torrent), so startup latency will be lower.

> I am not favoring of this if this were the case. After 
> all, there are many other schemes used in practice. We are hard to 
> determine that merkle tree is mandatory.

I think the Merkle hash trees have some important properties (see
above). If there are other common (video-on-demand) protection schemes
that fit the bill we should incorporate them in the draft. What schemes
were you thinking of?

CU,
    Arno

---

From: Picconi Fabio <[email-masked]>
Date: Mon, 23 Jan 2012 14:06:38 +0100

> Sent: lundi 23 janvier 2012 09:51
> To: ppsp
> Subject: Re: [ppsp] Proposal to resolve Issue 10 + 13
> 

I meant that "node specification" sounds Merkle-specific, whereas "chunk specification" sounds more generic. In the case of Merkle trees, the chunk specification would consist of a node specification.

> used by other integrity protection schemes?

What I had in mind is a generic HASH message that can be used by other mechanisms. It probably makes more sense to call it INTEGRITY (or something like that) rather than HASH.

Fabio

---

From: Arno Bakker <[email-masked]>
Date: Wed, 25 Jan 2012 09:40:22 +0100

On 23/01/2012 14:06, Picconi Fabio wrote:
>
> I meant that "node specification" sounds Merkle-specific, whereas
> "chunk specification" sounds more generic. In the case of Merkle
> trees, the chunk specification would consist of a node
> specification.
>

Hi

I propose to formulate the ability to also address nodes as a MUST 
requirement when Merkle trees are used, and use chunk spec everywhere.

> What I had in mind is a generic HASH message that can be used by
> other mechanisms. It probably makes more sense to call it INTEGRITY
> (or something like that) rather than HASH.
>

I'm fine with a rename and generic message with an integrity 
scheme-specific payload.

CU,
     Arno