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

From: Picconi Fabio <[email-masked]>
Date: Thu, 29 Mar 2012 14:56:41 +0200

Hi,

So, a follow-up of what I said during the Paris meeting:

1) Regarding the content addressing mechanism, I think the mandatory solution should be one which is as simple as possible without compromising efficiency. Between bin numbering and the simpler list of ranges (e.g., run-length-style encoding), I would chose the second since implementing it takes 5 lines of code and the bandwidth overhead should be quite reasonable. So I would make bin numbering optional, unless you show that the bandwidth gain is significant.

2) Regarding integrity checking, somebody mentioned that forcing implementers to support a feature does not mean you have to use it in a given deployment. I think that should be the case for integrity checking. Now, if integrity checking is mandatory, we have to chose an integrity mechanism.

Paper [1] gives a nice comparison of four different mechanisms, and the trade-offs between CPU complexity, bandwidth, and delay.

"Sign-all" has the best delay but worst CPU complexity, "Merkle trees" has better CPU complexity at the expense of worse delay, and "sign-and-correct" has better bandwidth efficiency than Merkle trees at the expense of an even worse delay. The fourth mechanism is not so interesting as it increases bandwidth overhead to achieve only a very small reduction of CPU.

I think that "sign-all" and "merkle trees" are both good candidates, as there is a CPU/delay trade-off: 

2.a) sign-all: better delay, worse CPU complexity
2.b) merkle-trees: better CPU complexity, worse delay

Since sign-all is *significantly simpler to implement* that Merkle-trees, and the group seemed headed towards making merkle-trees mandatory anyway, I would suggest making support for both mandatory, thus supporting low-delay applications.

Cheers,

Fabio

[1] Pollution in P2P Live Video Streaming, by Prithula Dhungel, Xiaojun Hei, Keith W. Ross1 and Nitesh Saxena.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Picconi Fabio
> Sent: lundi 23 janvier 2012 14:07
> To: [email-masked]; ppsp
> Subject: Re: [ppsp] Proposal to resolve Issue 10 + 13
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
> > Arno Bakker
> > Sent: lundi 23 janvier 2012 09:51
> > To: ppsp
> > Subject: Re: [ppsp] Proposal to resolve Issue 10 + 13
> >
> > On 19/01/2012 15:12, Picconi Fabio wrote:
> > > 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.
> > >
> >
> > 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?
> 
> 
> 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.
> 
> 
> > > 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?
> 
> 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
> _______________________________________________
> ppsp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ppsp

---

From: zhangyunfei <[email-masked]>
Date: Thu, 29 Mar 2012 22:12:12 +0800

Hi Fabio,
    For point1,+1.(Speaking individually)
    For point 2, I fail to download the reference paper. Can you say more words about "sign-all"? And is there possible that we have a way to balance bw sign-all and merkle tree? It would be great if we can get that.

BR
Yunfei

zhangyunfei

From: Picconi Fabio
Date: 2012-03-29 20:56
To: [email-masked]; ppsp

Cheers,

Fabio

---

From: Picconi Fabio <[email-masked]>
Date: Thu, 29 Mar 2012 16:23:05 +0200

Hi Yunfei,
Here's the link to the paper : http://cis.poly.edu/~ross/papers/pollutionStreaming.pdf
The "sign-all" means that the source signs every chunk and appends the signature to the chunk contents. It's costly in CPU terms, but incurs no delay.
Fabio

From: zhangyunfei [mailto:[email-masked]]
Sent: jeudi 29 mars 2012 16:12
To: Picconi Fabio; [email-masked]; ppsp
Subject: Re: Re: [ppsp] Proposal to resolve Issue 10 + 13

Hi Fabio,

BR
Yunfei

________________________________
zhangyunfei

From: Picconi Fabio<mailto:[email-masked]>
Date: 2012-03-29 20:56
To: [email-masked]<mailto:[email-masked]>; ppsp<mailto:[email-masked]>
Subject: Re: [ppsp] Proposal to resolve Issue 10 + 13
Hi,

Cheers,

Fabio