Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Uber-like CDN

medium.com

Post reply on HN
Print view View original

41–50 of 86 posts

Re: An Uber-like CDN

#41

Post by illiarian »

pwinnski wrote: post #25
mranton wrote: post #14

Earlier quoted context omitted.

>1. Performance. In terms of latency, this is adding an extra round-trip to each page request (to get the metadata). It's also likely going to load different resources from different servers (hostname, IP) preventing connection reuse. I guess they can't even start fetching data until the full page has loaded? fair point. We use same technique as lazy-load (you have to wait the full page has loaded). >3. Economics. If…

Three things about "how Uber works": 1. It started out burning huge amounts of investor capital, basically transferring all of that money to drivers and in the form of subsidized rides, to riders. 2. It works today by a combination of the above and underpaying drivers, who generally make less than minimum wage when they manage to cover their completely costs at all. Despite this, prices have gone up dramatically, so…

1. Is basically price dumping using unlimited investor money and is blatantly illegal. But since it "this great big disruptive innovation unicorn", no one batted an eye. And still no one bats an eye in 3. :)

Re: An Uber-like CDN

#42

Post by jedberg »

mranton wrote: post #18
jsnell wrote: post #7

There's a bunch of really obvious objections to this idea around performance, privacy, economics, UX, and reliability. Impressively, the post did not manage to address any of them up front. 1. Performance. In terms of latency, this is adding an extra round-trip to each page request (to get the metadata). It's also likely going to load different resources from different servers (hostname, IP) preventing connection reu…

>1. Performance. also please note: if you have 1 image on the page - we have to do 2 requests (1 metadata, 1 download) if you have 50 images on the page - we have to do 51 requests only (1 metadata for all images, 50 downloads)

> if you have 50 images on the page - we have to do 51 requests only (1 metadata for all images, 50 downloads)

But unless you return the same host for 50 objects, I'm going to have to do a bunch of DNS lookups too, right? And a bunch of SSL setups.

Hopefully you at least make sure to try and return a single host for all the objects in a request.

Re: An Uber-like CDN

#43

Post by jedberg »

This sounds a lot like CoralCDN. You should look them up, they had some good papers. We actually used CoralCDN on reddit for a while, where we'd send users to the CoralCDN link of the webpage they were trying to get to instead of the actual page. It sadly didn't work very well.

Here is one of their papers: https://www.usenix.org/legacy/event/nsdi10/tech/full_papers/...

Re: An Uber-like CDN

#44

Post by mranton »

uncertainrhymes wrote: post #38
mranton wrote: post #27

Earlier quoted context omitted.

>a CDN isn't just about bandwidth, it is about _disk_ The disk performance - is the weakest part of the Peer. It is a part you can't guarantee any QoS on a cheap server. The idea is to keep popular cache on Peers in memory. Everything else we will host from a limited number of regular servers (belong to Farba), with high-performance disk subsystem. >Cache management (eviction, invalidation, etc) is done where? yes. Y…

Your example servers have 16-32 GB of memory, which is basically nothing. If you ever ramp to real world traffic the peer will be constantly evicting objects (if you use a normal LRU). Even if you backstop that with a mid-tier belonging to Farba to protect the origin, what kind of cache hit rate are you expecting at the peer?

>Your example servers have 16-32 GB of memory, which is basically nothing

we just need to add more Peers and evenly distribute the workload.

> what kind of cache hit rate are you expecting at the peer?

I don't know. We have too many moving parts right now and can't predict anything.

Re: An Uber-like CDN

#45

Post by dedalus »

eastdakota wrote: post #11

Travis built RedSwoosh ( https://en.m.wikipedia.org/wiki/Red_Swoosh ) and then went on to build Uber. Now someone saw Uber and claims it inspired them to rebuild RedSwoosh. ¯\_(ツ)_/¯

Quite an honor to see Matthew Prince (CEO of Cloudflare) chime here.

Akamai acquired RedSwoosh precisely on the same economics promised and if this were economical/viable they would already have deployed it, no?

I did hack with Travis on RedSwoosh code base optimizing his TCP Zipper algorithm which was pretty cool BTW

Re: An Uber-like CDN

#46

Post by mranton »

jedberg wrote: post #42
mranton wrote: post #18

Earlier quoted context omitted.

>1. Performance. also please note: if you have 1 image on the page - we have to do 2 requests (1 metadata, 1 download) if you have 50 images on the page - we have to do 51 requests only (1 metadata for all images, 50 downloads)

> if you have 50 images on the page - we have to do 51 requests only (1 metadata for all images, 50 downloads) But unless you return the same host for 50 objects, I'm going to have to do a bunch of DNS lookups too, right? And a bunch of SSL setups. Hopefully you at least make sure to try and return a single host for all the objects in a request.

>Hopefully you at least make sure to try and return a single host for all the objects in a request.

our goal is to saturate the _User's_ network. Now it's hard to say how many Peers we need to meet this requirement. It looks like 2-3 Peers are enough.

Also, when you have 50 Peers, you have to do 50 DNS/SSL requests in _parallel_. With current hardware, it's not a big deal.

Re: An Uber-like CDN

#47

Post by nso »

jedberg wrote: post #43

This sounds a lot like CoralCDN. You should look them up, they had some good papers. We actually used CoralCDN on reddit for a while, where we'd send users to the CoralCDN link of the webpage they were trying to get to instead of the actual page. It sadly didn't work very well. Here is one of their papers: https://www.usenix.org/legacy/event/nsdi10/tech/full_papers/...

One of the problems I have with the VP of the product discussed is that while I trust CloudFlare, Akami or any of the big players, to run a tight network -- with high and STABLE performance -- I can't say the same about a random vendor (uber driver?) in this network.

Was the issues you were seeing in this general area?

Re: An Uber-like CDN

#48

Post by mranton »

jeroenhd wrote: post #24
amalcon wrote: post #4

Something doesn't add up here. They're actively telling third parties to lease cloud servers with large amounts of free bandwidth, and allocate them to this purpose. I see four possibilities: - They are paying the third party less than what it costs to rent the server, in which case the third party is losing money and shouldn't be doing this. - They are paying the third party at least what it costs to rent the server…

I think it's quite simple. The math adds up, they just want third parties to network with them. The more servers join this system, the more their product is worth. At the same time, the cost of managing hundreds or thousands of servers is moved to others. The more this trick will be used, the higher the cost of the dedicated fast internet connections with cloud hosts will become. Most people buying dedicated, unlimit…

Thank you, @jeroenhd, you got it right.

>now your battery-starved mobile phone is validating cryptographic signatures

with a native app, it costs nothing. Actually, the main power consumer is the phone screen.

>who's responsible for illegal content hosted on servers

this is a very important question. We are going to run AI models against all content we host on Peers. Right now, we don't accept third-parties and "fake" all Peers ourself. Want to ask lawyers what is the best way to handle this case.

Re: An Uber-like CDN

#49

Post by mranton »

eastdakota wrote: post #11

Travis built RedSwoosh ( https://en.m.wikipedia.org/wiki/Red_Swoosh ) and then went on to build Uber. Now someone saw Uber and claims it inspired them to rebuild RedSwoosh. ¯\_(ツ)_/¯

>The Red Swoosh peercasting tool is a _browser_extension_ that caches data, reflecting and sharing files delivered through the "Swoosh network"

I don't know how it works in details, but it looks like you need to install a browser plugin to enable the p2p network here.

Our solution works transparently for the end user.

Re: An Uber-like CDN

#50

Post by pwinnski »

mranton wrote: post #46
jedberg wrote: post #42

Earlier quoted context omitted.

> if you have 50 images on the page - we have to do 51 requests only (1 metadata for all images, 50 downloads) But unless you return the same host for 50 objects, I'm going to have to do a bunch of DNS lookups too, right? And a bunch of SSL setups. Hopefully you at least make sure to try and return a single host for all the objects in a request.

>Hopefully you at least make sure to try and return a single host for all the objects in a request. our goal is to saturate the _User's_ network. Now it's hard to say how many Peers we need to meet this requirement. It looks like 2-3 Peers are enough. Also, when you have 50 Peers, you have to do 50 DNS/SSL requests in _parallel_. With current hardware, it's not a big deal.

> With current hardware, it's not a big deal.

You should make this your marketing slogan.

"Try our CDN, with current hardware the gross inefficiencies other CDNs spend a lot of time and effort eliminating are not a big deal."

Post reply on HN