jsonified

Only sensible comment I've seen so far. Nicely put @dbloom.

nice to see even in sort() we have innovation!

atm I'm not doing live streaming so I can store & reload these from disk. I'm likely to end up using hipe_bifs:bitarray* or https://github.com/ferd/bitarray where those are not available, if needed. See http://erlang.org/pipermail/erlang-questions/2009-May/043485... for an example.

physical attendance at the conference costs; it's minimal for a day session for a student, but its possible to listen in remotely.

Jamii I've seen your ocaml implementations, your code has been very instructive - thanks!

Hi Dan,

good points -- but they're not the scenarios I'm referring to, and they're extremes around a perfectly usable for 90% of use cases & users.

If Joe wants to stream to Barney and a handful of people then his laptop is fine. If he want to push 10k, then obviously he'll need some help, the maths doesn't stack up any other way. Your original example (and my response to it) mentioned a pair of users with a need for low latency. 10k is obviously going to be different, and we both know that. Let's not be disingenuous here.

PPSP-TP (the tracker protocol) doesn't force Joe's laptop to be the seeder for the entire 10k, it can be managed as discrete swarms, and the tracker protocol can segment or insulate the seeding peer from a larger community if required. But as you rightly point out in this case, help is needed. There's a limit on how much can be streamed based simply on packet size & transfer, even though PPSP is much more efficient than existing protocols due to the way it handles hash management (merkle trees and munro hashes) bandwidth is bandwidth, (latency & asymmetric aside).

Again, PPSP is a transport protocol, not just a live video stream. There are applications even in areas where bandwidth is 100Kb/sc or worse.

If you're really interested in this, please read up on the protocol and contribute some much-needed real world feedback to its development. The next IETF session is, as always, publically accessible, https://datatracker.ietf.org/meeting/89/agenda/ppsp/ next Tuesday 16h10 GMT. It would be great to have you join us!

the PPSP one, if you're going to be around at IETF let's discuss there.

https://datatracker.ietf.org/meeting/89/agenda/ppsp/

Please read the PPSP protocol more carefully, your statements are invalid.

#1 if Jose is streaming to Sue, there's no middle server here. PPSP doesn't mandate a "central server", and I hope on the swirl website I can make this use case clear too.

I'd love us to be able to stream from our devices to friends etc and not need to store everything on youtube or dropbox or some other indexed/sliced/diced/resold for profit system. With PPSP however you could have your home network be a peer, and pull down the content safe and sound with minimal impact to your phone. This type of sharing is something I would love to roll out for journalists in the field, protesters in Venezuela and Ukraine, where media suppression by the government and confiscation of phones is a sad reality.

#2 Spoken like a true American ;-). This is not the reality for 99% of the internet users. I'm unable to get more than shoddy ADSL, even in a major European city. What about India, China, Africa, South America? Places where the monthly income is not even close to $200. Hopefully that will change over time, but it's not practical for most people today.

I concur that live P2P streaming is tricky, and I'm sure you have plenty of practical experience to back that up.

PPSP allows DVR style seek / record, the way the protocol is laid out makes that almost trivial. Now if your device at home doesn't have that content, you'll need to retrieve that from a peer, and I'd like to see that peer be close to you.

Today, with bit torrent & friends, there's no standard implementation to refer to, so there's no way for an ISP to put an intermediary cache in to support the functionality you want, assuming you're paying a premium for that content, which is what is done with HTTP & friends on a regular basis.

By having a standard protocol in place, multiple implementations & vendors can share the same caching peer technology within a single telco's network. Those peers can be located at edges within the exchange, similar to how major CDNs and google etc do today.

Finally, PPSP is more than just streaming, it's a completely new transport layer protocol for the internet -- like HTTP, we're only just beginning to explore the use cases.

Streaming should be free, as should the protocol it's developed on top of, so anybody can use it, and trust it.

Revenue streams come from supporting the back-end telcos (billing, active traffic mgmt & shaping), and content generators (disney/pixar etc), and a couple of other things I'm not ready to talk about just yet ;-).

We're going to be discussing WebRTC & PPSP together at the IETF meetup next week in London. I see WebRTC as a browser technology atm, so effectively a potential PPSP client and seeder. PPSP's aimed squarely at one-to-many sharing, so maybe there's some cross-over for video conferencing, but I'm not too familiar with it to say for the moment.

BTW googling IETF acronyms isn't easy -- try UDP, TCP, HTTP... ;-).

The protocol's described here http://tools.ietf.org/html/draft-ietf-ppsp-peer-protocol and there's a corresponding tracker protocol that's not finalised either.

These are drafts and in theory can change at any point in time.

I'd love to talk further with you about that.

Not yet, but integrating with apps like dropbox or similar etc is a nice feature, I'll add that to the official list.

PPSP's key features are:

- live streaming using an innovative method that can be easily secured

- optimised for fast start

- using a standard protocol (UDP) for maximum carrier friendliness

- efficient storage of hash tables via binmap

- use of merkle trees for verifying content without needing the whole hash table to be transferred to every client

- LEDBAT for playing fair with other bandwidth on the client connections

More details on these https://github.com/skunkwerks/swirl/blob/feature/docs/doc/me... and also in the IETF spec http://tools.ietf.org/html/draft-ietf-ppsp-peer-protocol

Your tech sounds cool but I don't think it's open source ;-). If you are at IETF89 in London next week, I'd love to talk P2P streaming. I'm @dch__ on twitter.

Hey, I'm the lead developer of swirl project. I'd like to add that I wouldn't be working on this today without the support of NLNet who has provided a grant that allows me to work on swirl full time atm: http://nlnet.nl/project/swirl/ Huge props.

Hi, I'm the author of swirl, such as it is. In principle there's nothing stopping you from streaming anything with PPSPP. The current erlang implementation could run on an android tablet for example. And if you had a pcell nearby http://venturebeat.com/2014/02/20/steve-perlman-pcell-is-rea... then b/w really wouldn't be a constraint.

There's a fair bit of work remaining, in particular browser/client support is something I've not even considered, it's not my speciality.

I'm sure VLC and Firefox etc would be awesome clients, but one step at a time.