Hi HN, I’m Shachar, co-founder and CTO of Peer5 - A P2P CDN for Video
We started Peer5 4 years ago, when we heard about WebRTC, and thought this is a ground changing technology that fundamentally change the way the web could work. Yea, and also because we’re geeks that love cool technologies like that.
I’ll be here to answer any questions, and get feedback from you guys.
When you run "pktstat -n" while watching the video, you can see the IPs of other visitors of the website. I see people from Sweden, the USA, Japan, Brazil...
Since among the HN users there are probably a lot of developers, I tried to put some of the IPs into my browser. And indeed, already the second IP I tried sent back a reply from a (misconfigured) server.
I have to say it feels frightening, that the other users can see my IP. And probably other data about me.
Also I would expect it's not legal in most places around the world to give away the IP of a visitor to other visitors. Can't imagine it is legal in Europe.
I agree that it's a bit frightening, but I would put that more on the browser makers than sites in general.
The various browsers decided that webrtc (websockets as well) didn't need to follow the "same origin" rules that they set up for XmlHttpRequest.
It almost feels like browsers should have some way to delineate "web pages" from "web applications" and provide different ways to present them to end users, different rules, etc.
That seems to work for now, but I'm thinking more of where it's headed. Websockets, WebRTC, WebWorkers, and then other pending proposals all eventually end up being like a "VM" running apps on your local machine.
At some point, it's much closer to an "App Store", which arguably has finer grained (and more usable) control presented to the user to manage what applications can (and cannot) do.
When a user access any website of content providers online, they implicitly agree to the terms of service of that provider. When using Peer5, the terms of service includes a language about public IP temporarily visible to other users.
This line of thinking makes me feel uncomfortable. That you can secretly give away data about me and which videos I watch because of some text in your TOS.
I also doubt it would hold in court. TOS have a very restricted applicability. You can not use them to restrict people's rights in unexpected ways.
True in the US, not true in the EU. There is a reason Google Analytics has a switch to throw a few bits of an IP away, and it surely isn't because Google hates data.
Given that they are selling a CDN, and thus likely want to sell to globally operating customers, that might become relevant relatively quickly.
More importantly they are also basically 100% allocated, so it's not like, say, telephone numbers where there are large unused swathes of the numberspace.
the interesting thing about a phone number also isn't if it is active or not, it is who it belongs to/what other activity originates from it. Knowledge about an IPs activity wouldn't be more useful if there were billions of unused IPs. E.g. introduction and rising adoption of IPv6, with massive unused space does not make data about an IPv4 address worth less.
ISPs like Comcast have metered caps (1TB for our home).
So now it will require ~2x bandwidth (down/up) to watch the same content. Basically shifting the content provider's CDN costs (which we pay subscription for) on the backs of consumer's metered internet? Seems like a triple whammy for consumers.
Is your expectation/hope that they will share some of their cost savings?
A: No. Peer5 can never deteriorate user experience.
Q: How does Peer5 impact a user's upstream bandwidth?
A: Peer5 works with whatever bandwidth is free for upstream use and will not impact other applications that require uploads at the same time as Peer5. Changes to upstream bandwidth are unnoticeable to the end user.
---
The concept is great, but until every consumer internet service comes with unmetered bandwidth, this kind of peer-to-peer CDN must be treated as what it is: a dark pattern from content providers who are looking to save their own bottom line while directly harming their customers in the process.
For every $1 a content provider saves by using this service, their users who happen to not have unmetered bandwidth will collectively pay dozens or hundreds of times that cost in overage fees to their ISPs. The fact that any business would use this technology and shrug their users' suffering off as an externality is disgusting to me.
> A: Peer5 works with whatever bandwidth is free for upstream use and will not impact other applications that require uploads at the same time as Peer5.
That would also require WebRTC traffic to be properly tagged as low-priority and general consumer gear being any good at QoS, neither of which is the case. Of course parallel uploads can and will have a negative effect.
Part of WebRTC's requirements [1] is to be fair on competing TCP connections.
This is a very good point, because I agree with you that in general parallel connections cause each connection to have less throughput, but if those connections have a mutual goal to download the same content it can actually increase the overall throughput than downloading that content via a single TCP connection. That's especially true when those connections are to different sources which can workaround specific network issues you might have in a single connection.
Actually the value proposition for our customers is to improve the QoS. And we've shown that's the case in customer case studies.
Let's take a step back and consider the problem that Peer5 is trying to solve: poor stream quality, especially as audience size grows. If you don't believe that this problem is real, then why do we see stories like these in the press:
Peer5's goal in life is not to give content providers / broadcasters a way to somehow cheat on their CDN bills at the expense of their paying subscribers. Rather, it is to improve the user experience (and value proposition) for everyone who is paying to stream video. I doubt anyone would find that "disgusting".
Yeah, I was about to say that the GP is overly pessimistic on the technology, since you could always detect metered ISPs and do something different for those (no upstream but lower priority downstream in exchange, for example). In the end, consumers of this CDN also don't want to be known as "that website which caused a 4x internet bill".
>> you could always detect metered ISPs and do something different for those
I didn't downvote, but this isn't possible for nearly all users. Whether or not you are metered isn't per-ISP, it depends on your monthly plan with the ISP. Most ISPs serve the majority of their users on metered, with some users paying for the high-end unmetered plans. There is no way to know whether a particular user is metered or unmetered.
Rural Australia here. 40gb satellite limit each month, uploads are counted. Everything we do has to be decided to be "worth it" when you have ~1Gb/day. No YouTube (no video in general unless really needed), no big images. Data is precious and expensive here.
I really doubt these guys are doing any effort in working with my tiny rural ISP. Nor would my or any satellite ISP ignore uploads because some US startup asked them to (they won't even unmeter any content for us like bigger ISPs do).
Something like this would destroy my quota, and I'd treat it as hostile like malware running background torrents or background software updates that don't prompt you (PS4 used my entire quota in one day once, while it was turned off.. that's how I learnt about PS4 standby mode updates! We had no net for nearly a month after that).
So you're against, net neutrality? All traffic should be treated equally, no one, or company should be able to have a "free lane" as you're suggesting.
Cool concept, but I agree with the rest of the criticism here.
Grats on your launch! I echo the sibling comment that was slightly faster in asking about the disconnect between p2p companies and profitability. There has been no shortage of efforts that tried to capitalize (and monetize) on the success of 'bandwidth sharing' that was perhaps brought to the forefront by BitTorrent, although pioneered before by early p2p networks.
Most of these companies appear to have faltered, while a few of them were bought out by big companies (example: [1][2]) and their technology has yet to be conclusively observed in the wild. Yet another class continues to run their offerings, but has drastically toned down marketing (example: [3]) There are also a good number of non-commercial explorations in this space, of various quality, from toys to demos to full-fledged networks. How do you plan to distinguish yourself?
2. Irrelevant: what tech people (i.e., the actual decision makers on becoming your customer) will immediately think is "look they plagiarised HTML5's logo", not "let me go through their site to see whether there's attribution" :)
What differentiates our solution from previous P2P services like BTDNA, Pando is the underlying technology stack - WebRTC, that eliminates the number 1 barrier - user needed to download and install a plugin. From the research we've done by talking with all of those previous solution was that was their number 1 barrier.
Our goal is to improve video user experience, and enable the full transition of TV to the web.
This was done already, almost a decade ago. CNN.com used it and it was total hell for us, running a corporate LAN, because it flooded out our upstream bandwidth, especially when multiple people used it. Their product ended up being considered, basically, as malware:
That's interesting, I know about Octoshape. But didn't know that in enterprise they actually made matters worse.
The way our technology works is a bit like an 'onion' architecture. Users from the same corporation should communicate only with each other - and actually reduce the traffic on their internet connection - making the user experience better.
That's fantastic if that's the truth. I'm not sure how you deal with this. Big corps have many subnets so you need a reliable way to figure out who's link-local.
Octoshape really was a disaster. During a major news event, many hundreds of employees could be live-streaming CNN and the effect was catastrophic.
Hey everyone - this is Michael Seibel - I'm one of the group partners for Peer5 and I'm really excited they have launched. If you have any questions for me - feel free to ask :)
I doubt you remember, but you responded very briefly to a YC application about nearly the exact idea complete with prototype work a couple years back. Didn't get any real interest or feedback from you though.
Has the game changed to make webrtc P2P platforms more palatable to VC (cough Trump = end of net neutrality cough) or did these guys just feel like better "founder material" to y'all? I mean, we weren't ever going to propose selling other's people bandwidth as a profit method for our tech, so maybe that's the problem.
FWIW, we've since moved on to something better. Realized that VC shouldn't be involved with every piece of tech, and that peer-distributed networks is probably one of those. I'm sure you'll see it show up on HN before too much longer though.
Glad your onto something better, but I think you know it's absolutely unproductive to try an infer anything from any single VC decision, for a variety of reasons.
To start they are wrong most of the time (just like we as entrepreneurs are wrong most of the time). Most unicorns have investor rejection stories.
If they were not wrong and there was a flaw with your plan/product or team, that kind of thing you can find out easily enough from people you trust and respect, and who won't feel bad about damaging a potential future business relationship.
I was (and truthfully still am) a little bitter over the whole experience (watching Silicon Valley for the first time was sort of a cathartic experience). So many people seemed interested at first, but it was so hard to get real feedback. Out of about 10 or so meetings, only one VC (depressingly it was the very first one we met with) listened intently and asked good questions. He gave great feedback but didn't want to pursue it because his tech consultants didn't think WebRTC was mature enough to work as we described. Every other time it was "Can you just go over the deck you sent 2 weeks ago? (which we did as they looked at their phones the entire time)" or "Great, but can you make this more enterprise-y by adding SLAs? (yes, their tech person asked if we could add enterprise SLAs to p2p video streaming)".
None of us were people with a wealthy or well-connected family, a degree from an elite school or even from a state with much of a culture for entrepeneurship or technology. So setting up meetings, building a deck and pitching it, the whole thing felt so extremely foreign. What I would have given for someone who we could trust or respect to give real feedback.
Nice thing about software though, as long as you have income to support yourself and are adequately skilled at your craft, you can just build it yourself. Which fortunately is the case here.
Has there ever been a business with significant commercial success that designed a peer to peer architecture to serve as the foundation of it's technology or IP?
I can only think of one, that being Skype. Of course that doesn't mean Peer5 can't do it, and I sincerely hope they do because I always root for entrepreneurs.
However there seems to be this weird disconnect between p2p architectures and profitable companies, even though the theory is so powerful. I can only guess as to why:
- The illegal stuff has somehow unfairly tarnished public opinion
- It's too low level and is only suitable for standards like WebRTC where lots of people buy in at once to provide enough momentum
The cost of delivering content is not zero. The main variables are the codecs & quality of a stream, which on average is going up, and the cost to deliver (bandwidth/storage). The cost deliver keeps going down.
So, there are periods of time, when a p2p approach "looks" nice. 4k? Maybe all this live-streaming stuff? Sure. But what happens is the cost of delivery with HTTP keeps going down.
Joost had a bunch of other issues that made it fail, un-related to the use of p2p.
p2p might be cheaper to operate for a business, but it has almost no advantages for users over a well built CDN. For users it only has negative attributes (baring a few situations on LANs / getting streams into places you can't put a CDN).
Prices do go down, but consumption goes up in a faster pace. So overall companies pay more for CDNs for video :)
The thing is, even if CDNs would be free, they have limited capacity and they saturate during large live events. That's one of the reasons we still watch sports on pay-tv.
>Prices do go down, but consumption goes up in a faster pace
Not true. It varies based on what's in vogue on the content side, quality requirements, and the state of technology at a given moment in time.
As one point of reference, Flickr posted an analysis here recently that discussed how their architecture has evolved over time based on variable ratios of usage requirements and hardware costs.
"Why the hell is Chrome uploading and downloading so much data?"
* looks through open tabs *
"Oh."
Though most people would never notice, I feel like with developers (the folks who will implement this on their sites) you may have a tough time convincing them this is safe and ethical. I suggest being up front about this issue and suggesting disclosure/consent strategies to any of your customers (and perhaps doing research and surveys to prove that nobody really minds this use of their bandwidth).
Also, it's kinda weird that you've appropriated the HTML 5 logo into your own. That's probably within the logo's Creative Commons license, but I don't see where you've given attribution as required by said license.
Slick page though, and a good informative site... I don't mean to be a downer. Good luck!
> Only data delivered via P2P counts against your plan.
Am I misunderstanding this or is that statement backwards?
Isn't the point of a P2P network to get the distributed network benefits of your user base and if so why would I pay for that versus the data that's coming directly off the primary channel?
Presumably the more traffic the P2P stuff serves, the more value it brings you (in saved CDN costs), and of course Peer5 would like to be paid as much as possible of that. Being paid by the same measure the thing you are replacing is commonly billed by seems sensible.
I was going to ask the same thing. The Accounts & Billing FAQ does seem to concur that you pay for P2P delivery:
> A: For the pay-per-Gigabyte tiers, Peer5 charges you at the end of the month based on the agreed upon price and actual amount of data delivered through our P2P CDN during the period. For the Pro tier, Peer5 bills the flat rate at the beginning of the month. For the free, Starter tier, there is no billing, but we do cap your P2P delivery at 1 TB per month.
The idea is that you're not double taxed. If you're using a CDN already like Akamai for instance, you wouldn't pay Peer5 for the HTTP bytes. Only Akamai would charge you for that.
But why bill based on the bandwidth at all? Is it just a matter of being easy to understand and will equate to more than request based billing?
With a P2P network the bandwidth isn't being paid for anyway as you're using the end user's outbound connections. The tech behind it does sound interesting but it sounds more like a library than a metered service.
traffic is as localized as possible. As a general rule you can think of, if the peer is more local to you than the nearest CDN PoP you'll receive data from the peer, otherwise you'll receive data from the CDN.
>Cool! Does this mean all peer traffic is local ? Also, how can you detect when traffic is metered ?
We combine both client side and server side methods for that.
This is cool from a philosophy of the internet angle. It's also one of the worst workloads to try with P2P so it will be interesting to watch as a business.
There are a number of fundamentally half-duplex technologies in widespread use, such as wifi. Others have very different transmission characteristics, for instance tx uses a second frequency on cellular but is obviously more power hungry, whereas DOCSIS, wifi, and pretty much any radio network have batching and even ack filtering that make ack clocking or even state of the art things like BBR congestion control difficult. On "eyeball networks", ISPs provision for downstream ratio and wholesale upload bandwidth to businesses as transit. That may manifest as policy such as upload caps, or monetarily. Drastically changing their network profile is more likely to result in hasty policy and financial games rather than re-architecture or capacity expansion.
Also fundamentally, TCP is "easy" as a receiver and most stacks in common use are good receivers. TCP as a sender is hard, and most stacks have a ways to come, aside from sub-optimal defaults.
Hard problems. Doesn't mean there aren't simple solutions like aggressively clamping where the tech is used. It also might spring the problem on other people (ISPs, and I mean this non-condescendingly but end users) in a way that is eventually a net win.
Right, that's a great point.
We take into account whether your mobile device is currently using Cellular or Wifi and make decisions based on that. (Today Cellular devices would not be uploading at all, just leeching)
It's a little amusing how we see many stories with comments begging for more "decentralized platforms", and when one ships people go "wait.. they can see my IP?".
This sounds like Red Swoosh, a company Travis Kalanick (Uber CEO) started and was acquired by Akamai back in 2007. I was surprised that Akamai is a partner. They already do that...
But anyways CDN is highly commoditized now and most big players are building their own solutions. What advantage do you offer? It does not seem like it would be a great solution for live streaming...
Also this sounds like a perfect target for DDoS attacks...
Indeed Red Swoosh was probably one of the first P2P CDN companies, the main difference from them is the underlying technology - WebRTC enabling a seamless experience for the end user.
CDN is still a very expensive business to bootstrap and most companies in the world rely on Akamai and Akamai like companies.
We provide a few advantages over a traditional CDN:
1. Geographically ubiquitous distribution - wherever there's demand, there's capacity.
2. Improved user experience - since each user can download content both from the existing CDN and multiple other peers it can fetch that content faster and be less exposed to network conditions between it and the CDN's PoP
3. Scale - CDNs as big as they are, even Akamai have a limit, and this pronounces it self the most specifically in live events. Today's biggest live events over the internet has been single digit million concurrent users and they were using several CDNs at the same time. The potential of a P2P CDN is to bring TV scale events to the internet.
Please elaborate how you think it can facilitate a DDoS?
Serverless CDN is the term we use to describe a CDN that uses no servers for the content itself.
It's actually a Peer-to-Peer Content Delivery Network. Big content providers (like Netflix, Youtube, ESPN) can use that to deliver their content more efficiently and improve their users' experience. That results in less rebuffering for their users and lower costs on infrastructure.
There are no downloads or plugins to make it work. All data moves through WebRTC after just a 2 lines of js. Web pages enabled with Peer5 look exactly the same as they did before it was implemented.
They could notice if monitoring upstream bandwidth, although this would be absolutley negligible on Wifi connections.
I did not expect that WebRTC would allow a website to make the browser deliver content to a 3rd party without the users consent. This has some strange privacy and copyright implications.
That's a very much talked about subject in the standardization groups. They've concluded that WebRTC doesn't add any additional privacy or security exposure than what exists in the browsers previous to it.
Can you please explain more why you think there are copyright implications?
I'm not sure about the US, but in the EU and in particular in my country of France, anti-piracy lawsuits have seen a very clearly drawn line between a mere downloader, and an uploader. That's what lead emule and bittorrent to be "dangerous" legally while direct downloading (newsgroup, rapidshare, ...) and streaming almost never led to conviction (even symbolic). That the user didn't realize his bittorrent was re-uploading content to others didn't matter.
So, if I visit a website to get, say, direct copyrighted content (let's say photo, comics, music, whatever) and that website uses webrtc to make me reshare it to other users, my legal status just went from a almost never convicted downloader to a very much punished (even though it stayed symbolic, it was still a legal loss) uploader.
What's different in the CDN use-case is that the content that reached a 3rd user through the uploading user would've reached the 3rd anyway, just from the original server.
Yeah but from the point of view of the (unexpecting) uploader that doesn't change anything. If user A wasn't uploading, user B would still get the files from other peers on the torrent, doesn't change the fact A was sharing and actively uploading the file.
Not trying to throw a wrench in your game, but I think this is something you guys need to have a look into because you're turning unsuspecting users into uploaders of content they have no control over, without noticing it, when it has been proven to cause them legal harm.
> They've concluded that WebRTC doesn't add any additional privacy or security exposure than what exists in the browsers previous to it.
Even the WebRTC standard talks quite a bit about it in the Privacy and Security Considerations section, some quotes:
Revealing IP addresses can leak location and means of connection; this can be sensitive. Depending on the network environment, it can also increase the fingerprinting surface and create persistent cross-origin state that cannot easily be cleared by the user.
[...]
These choices can for instance be made by the application based on whether the user has indicated consent to start a media connection with the other party.
On standards without additional exposure, this section normally says so and is otherwise empty.
Exposing other visitors IPs is a pretty massive leak (at least some jurisdictions consider them PII, with the consequences to match), presenting that as "no additional privacy exposure" is just negligent (or more likely intentionally misleading).
That's not true because you send or receive data from other peers only if you are already watching a video.
In other words - p2p is used only in places where the data would have gotten from the server anyways (e.g. p2p didn't add any new users to the equation)
You A are getting content from server S.
B is getting the same content from server S.
With this CDN, what changes is that A is now sending content to B. Content that may be illegal. The fact that would mean A was accessing illegal content doesn't change the fact that this CDN moves him from a downloader to an uploader, without his content nor telling him, something that has legal precedent for leading to convictions in europe.
This reminds me of PeerCDN, which was acquired by Yahoo 4 years ago. One of the founders, Feross, went on to build the excellent open source WebTorrent library using many of the same technologies. Glad to see someone actually doing this! How does it compare to PeerCDN?
Hi, Hadar here, Co-founder and CEO of Peer5.
PeerCDN started at about the same time as Peer5 and was a competitor. Later it was acquired by Yahoo.
PeerCDN was a general purpose CDN, while Peer5 specializes in video. Feross, one of PeerCDN's founders and author of WebTorrent actually became my friend and we exchange ideas from time to time.
Out of curiosity, what is being used to have the dots on the globe in the landing page? I've been trying to find out how to do this for a while, but I don't know which libraries are designed for it.
Any involuntary p2p, specially one that eats heavily into a quota, can be classified as malware. Is this a good criteria to ad-block the peer5 script URLs?
Please note that Peer5's p2p is not involuntary. Peer5 is not the broadcaster at the end of the day, our customers are. We work with our customers to notify users that their use of streaming services on a particular site may entail participation in p2p and to give them the appropriate opt-in or opt-our mechanisms. Anyone who doesn't want to participate is not forced to.
Yes, we agree with you that users should know that p2p is happening and that they can opt out. We work with our customers to notify users and to give them the appropriate opt-in or opt-our mechanisms.
I just know about the IPFS team, but not familiar enough with their stuff. From my experience usually a synchronization oriented distributed algorithm can be very different from what a use-case like Video On Demand, or Live video requires. In terms of chunk allocations, predictions of what's going to be needed and so froth. But I definitely should familiarize myself more with their stuff.
Yes it does, there'll be other parameters but the main goal is to find the nodes that'll help each other the most, and usually that'll be the closest ones.
Live streaming is the best use-case, where Peer5 has the most value to give.
Yup, we support both AES-128 for HLS and any Common Encryption based DRM, that's true because we're basically agnostic to the content it self we just deliver it more efficiently.
Hi @shacharz do customers approve that his device would be used in p2p work ? For example if I'm on cell network I don't want to server traffic to other clients.
We started Peer5 4 years ago, when we heard about WebRTC, and thought this is a ground changing technology that fundamentally change the way the web could work. Yea, and also because we’re geeks that love cool technologies like that. I’ll be here to answer any questions, and get feedback from you guys.
We've also just announced the YC investment (W17) and our new native Android SDK on TC (https://techcrunch.com/2017/01/26/peer5-y-combinator/) Thanks!