Re: [ppsp] PPSP WG Update

[zhangyunfei <[e-mail]>]

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
Subject: Re: [ppsp] PPSP WG Update
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



> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Picconi Fabio
> Sent: jeudi 7 juin 2012 15: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
> 
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] 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)
> >
> > 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
> > _______________________________________________
> > ppsp mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ppsp
> _______________________________________________
> ppsp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ppsp
_______________________________________________
ppsp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ppsp