Re: [ppsp] PPSP WG Update

[Picconi Fabio <[e-mail]>]

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