Subject: [ppsp] PPSP WG Update

From: stefano previdi <[email-masked]>
Date: Mon, 4 Jun 2012 11:39:12 +0200

All,

here are some notes i preparation of the next PPSP meeting we're 
going to have in Vancouver (http://www.ietf.org/meeting/84/index.html)

1. Peer Protocol - chunk addressing mechanism
   We currently have two proposals that I'd try to name as:
. Bin Notation
. Ranges
   Both proposals have been discussed in the mailing list and it 
   looks to me we're NOT achieving agreement/consensus on any of 
   them also due to lack of participation of the WG into the 
   discussion (other than the authors of each proposal).
 
   Therefore, as of today, we can reasonably explore the 
   following options:
   Option-1: We propose both solutions in the peer protocol 
             specification and we define them both MANDATORY so 
             to cope with interoperability issues.
   Option-2: we select one option through a WG vote (this is my 
             least preferred option).
 
   Since I'd really prefer to avoid Option-2, I can only consider 
   the "dual" specification. WG opinion on this is requested.
 
   Again, it would be very beneficial to the WG if current 
   implementors of streaming protocols would/could speak-up and 
   give their opinion (see point 4 below).
 
2. Peer Protocol - Security Section
   The IESG will not accept any protocol specification without a 
   consistent security section (IOW: way more than what we 
   currently have) although there are some arguments on whether 
   we need the security mechanisms in the base spec.
 
   Arno and Zong Ning proposed some text and we need to agree/amend 
   it asap so to update the draft. I'd like to close this one and 
   have a new version of the draft for next meeting.
 
3. Tracker Protocol
   After IETF83 we agreed to split into two distinct drafts: base 
   specification and optional extensions.
 
   Authors, it would be good to have a first submission before next 
   meeting.
 
4. Survey draft.
   We need to refresh/re-submit and the chairs proposed the 
   authors/editors to include a section on deployment experiences 
   and more precisely on chunk addressing and security mechanisms. 
   Hopefully this will also feed ongoing discussions.
 
5. Meeting during IETF84.
   We have requested a slot for Vancouver meeting. Anyone 
   interested, please request an agenda slot asap to Yunfei or 
   myself.
 
Let us know if anything is missing.
 
Thanks.
 
Stefano & Yunfei

---

From: Arno Bakker <[email-masked]>
Date: Tue, 5 Jun 2012 09:05:11 +0200

Hi all

please see inline.

>               to cope with interoperability issues.

As long as they use the same division into chunks (e.g. required by the
Merkle hash tree for content integrity protection) there should not
be a problem translating bins to ranges and vice versa. Note there are 
two possible types of ranges: ranges of chunk IDs, and
byte ranges.

I'm currently updating the -01 draft following the issues raised since
January, which includes freedom to have different addressing schemes and 
the two proposals.

> 2. Peer Protocol - Security Section

Part of the update the security section is extending the
security analyses and solutions discussed since January.

The update will give us a draft that addresses all major topics,
with some strategic decisions to be made on default transport,
and extra features to add or reject.

We hope to have a new version next week.

CU,
     Arno

---

From: Rui Cruz <[email-masked]>
Date: Tue, 5 Jun 2012 09:22:56 +0100

Hi,

The Tracker Protocol is  being split to a base specification draft and to extensions.
We hope to have the base specification submitted in a couple of weeks. 

Regards,

Rui Cruz
[email-masked]

IST/INESC-ID/INOV - Lisbon, Portugal
__________________________________________
ppsp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ppsp

On 04/06/2012, at 10:39, stefano previdi wrote:

> _______________________________________________
> ppsp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ppsp

---

From: Picconi Fabio <[email-masked]>
Date: Thu, 7 Jun 2012 15:02:26 +0200

I will do some simulations to determine which chunk addressing mechanism performs best in the average case.

Fabio

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> stefano previdi
> Sent: lundi 4 juin 2012 11:39
> To: ppsp; zhangyunfei Zhang
> Subject: [ppsp] PPSP WG Update
> 
> All,
> 
> here are some notes i preparation of the next PPSP meeting we're going
> to have in Vancouver (http://www.ietf.org/meeting/84/index.html)
>

---

From: zhangyunfei <[email-masked]>
Date: Mon, 11 Jun 2012 09:33:27 +0800

Thanks Fabio. That will be good in making the protocol solid. Looking forward to your result. 

BR
Yunfei

zhangyunfei

From: Picconi Fabio
Date: 2012-06-07 21:02
To: ppsp
Subject: Re: [ppsp] PPSP WG Update
I will do some simulations to determine which chunk addressing mechanism performs best in the average case.

Fabio

---

From: Picconi Fabio <[email-masked]>
Date: Thu, 14 Jun 2012 13:39:58 +0200

Today I had some time to simulate the average cases overhead of the two chunk addressing mechanisms we've been discussing. However, before I started coding, the following popped into my mind:

As Arno pointed out before, if we assume that a peer sends very few updates per second to its neighbors, e.g., it waits until it receives 32K of contiguous data before notifying its neighbors, then the update traffic for a 1 Mbps stream is negligible (less than 1%) regardless of the chunk addressing mechanism.

Conversely, if a peer sends an update message to its neighbors for every chunk it receives, then the overhead is the same for bins or range lists, as each notification refers to a single chunk.

There is a trade-off between these two possibilities: in a live streaming application, delaying updates until one receives a full 32K block (to save signaling bandwidth) increases the chunk delivery delay. Notice, however, that the chunk addressing mechanism seems to be irrelevant.

In a progressive download application the diffusion delay is not an issue since the download rate is higher than the playback rate.

So I guess the question again is: what do we gain by using bins instead of range lists?

Fabio

> Picconi Fabio
> Sent: jeudi 7 juin 2012 15:02
> To: ppsp
> I will do some simulations to determine which chunk addressing
> mechanism performs best in the average case.
> 
> Fabio
> 
> 
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of stefano previdi
> going

---

From: zhangyunfei <[email-masked]>
Date: Fri, 15 Jun 2012 11:24:44 +0800

I agree with the selection of updating the chunk availability in an accumulated way. It's a reasonable choice even in a live streaming scenario because an unplayable chunk addition in the receiver is not useful for the viewer to watch more video.  Therefore an aggregation of some chunks information without  affecting the viewing is best. 
In fact, the current systems usually use a periodical exchange mechanism( say, several seconds or more).

Yunfei

zhangyunfei

From: Picconi Fabio
Date: 2012-06-14 19:39
To: ppsp

Fabio