4 ms·

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

by jsnell 4y ago

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 reuse. I guess they can't even start fetching data until the full page has loaded? And it feels like this scheme would make it much harder to reliably cache resources, since the browser will cache by URL while they'd struggle to make sure the URLs are stable across calls. 2. Privacy. Their threat model only addresses malicious peers changing content, not malicious peers trying to track users. 3. Economics. If running peer servers really was profitable, the company would do it themselves rather than outsource it. Given the "where can you get a server" section, it's not even that they're expecting this to just be running on spare capacity. The problem with the setup is that incentives of the peers are badly misaligned with the network, the clients, and the end-user. A peer wants to maximize traffic; the clients and end-users want to minimize it. So a peer would be incentivized to set cache-control headers to prevent caching, to increase traffic. Likewise a peer would be incentivized to only keep copies of the most accessed resources, to be able to serve as high a proportion of the traffic as possible with a given disk budget, while all the other stakeholders would like each file to be available just N+1 times in each region. 4. UX. URLs will be really crappy compared to a proper CDN. Right-click copy a link to an image and send it to somebody? It'll initially be to some super-dodgy URL, and stop working in a day or two as the CDN node starts caching different content. And AMP showed that people do actually care about URLs. It's pretty hard to take this seriously.

deleted 4y ago
[deleted]
mranton 4y ago
>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 running peer servers really was profitable Uber doesn't drive taxis himself, airBnB doesn't own property. This is how Uber-economy works. We believe it works in the CDN industry as well. We just don't want to be another CDN provider.
- pwinnski 4y ago
  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 that taxis are once again competitive on a price basis. 3. Uber was profitable in 2018, and not before nor since[0]. Deeply, profoundly unprofitable. Why would anyone want to be the Uber of anything? 0. https://www.macrotrends.net/stocks/charts/UBER/uber-technologies/net-income https://www.macrotrends.net/stocks/charts/UBER/uber-technolo...
  - illiarian 4y ago
    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. :)
  - chx 4y ago
    It always underpaid drivers. It exploited drivers not calculating car amortization costs and sometimes not even gas correctly. Also, people do not calculate the value of their time spent waiting (unpaid) and the cost to drive to the pick up (also unpaid). I guess Haraszti laughed his ass off when he learned of this bullshit. https://www.amazon.com/worker-workers-state-Piece-rates-Hungary/dp/0140219889 https://www.amazon.com/worker-workers-state-Piece-rates-Hung... He basically have proven the socialist state was paying factory workers only when their machine was actually working on a piece and then per the minute. And of course wrote a book criticizing the entire system on the side.
- bhaney 4y ago
  Completely skipping over the privacy concern doesn't seem like an amazing look
  - tedivm 4y ago
mranton 4y ago
>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)
- jedberg 4y ago
  > 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.
  - mranton 4y ago
    >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.
    - pwinnski 4y ago
      > 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."
- chx 4y ago
  > if you have 50 images on the page - we have to do 51 requests only (1 metadata for all images, How do you know the nearest peer has all the images at hand?
  - mranton 4y ago
    to answer this question, I will write another article how we distribute cache among the Peers. Long story short: - we divide web cache in buckets - these buckets have different sizes - we know a list of files in every bucket - we know what buckets every Peer has
paxys 4y ago
1 is something every CDN in the world already deals with. The metadata system ultimately needs to be its own little CDN, and can achieve the same level of performance (e.g. by deploying at the edge) just without the bandwidth costs. 2 is definitely an issue. 3 is a maybe. There's definitely a model where people with access to cheap servers and bandwidth can get on board and not have to worry about the application-level details, finding customers, billing etc. 4 isn't an issue as long as you are selling the CDN specifically for website assets that don't need to have pretty URLs.
- jedberg 4y ago
  > 1 is something every CDN in the world already deals with. Not exactly. For a normal CDN, your webpage HTML directs the client directly to the CDN server, which in theory already has the object. Only if it doesn't have the object does it need to go get it, but there isn't an extra lookup. The CDN does it's direction magic via DNS or IP routing, not with double lookups.
- jsnell 4y ago
  1. None of the issues I listed affect traditional CDNs though. 3. Why would the people running a peer have cheaper access to servers and bandwidth than a company specializing in that business? Everything about this business should have huge economies of scale (buying hardware, system administration, transit/peering). The only situation where I can see a distributed model winning out is if the entity running the peer does not pay for resources but gets them with fraud or theft, e.g. paying for cloud servers with stolen credit cards.
  - zamnos 4y ago
    It's a matter of locale. Having an entrepreneur in South Africa or Tibet hear about the money making opportunity, setting up a peer, and then paying them for it is better than flying there for a month to set up a business presence and figuring out all the local everythings. Akamai et al has already done this, and charge money commensurate with having done that. This group seems to be banking on someone in Kathmandu hearing about this opportunity and setting up a peer there.
x-complexity 4y ago
> 2. Privacy. Their threat model only addresses malicious peers changing content, not malicious peers trying to track users. I'm narrowing the scope around 'user tracking' specifically to 3rd parties, because 1st party user tracking is a requirement in order to perform some necessary functions (Providing accounts & user sessions, for example). In the current centralized CDN model (Cloudflare, AWS, Akamai, etc.), the 3rd party is made clear (those aforementioned companies), and their need to track users is documented on the provider's ToS. Likewise, reputational damage is accrued to the providers in question. In their proposed CDN model, there is no clear 3rd party, and so it must be defensively assumed that all of the data sent for requests is recorded at all times (The FBI Tor exit node problem). As a consequence, the minimal amount of request data can only be sent to these providers (IP address, content hash). Tor-like routing could be implemented to further disperse the requests from one IP address to multiple addresses, but now the monitoring problem's increased to the routers as well, on top of the additional latency introduced for said privacy. Mandating said routing into the protocol would make such tracks useless, as the IP address collected will roughly appear as random noise in the optimistic case. Personal opinion below However, it is likely that no technical solution provided would resolutely satisfy the question being asked.

by jsnell 4y ago

deleted 4y ago

[deleted]

mranton 4y ago

>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 running peer servers really was profitable Uber doesn't drive taxis himself, airBnB doesn't own property. This is how Uber-economy works. We believe it works in the CDN industry as well. We just don't want to be another CDN provider.

pwinnski 4y ago
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 that taxis are once again competitive on a price basis. 3. Uber was profitable in 2018, and not before nor since[0]. Deeply, profoundly unprofitable. Why would anyone want to be the Uber of anything? 0. https://www.macrotrends.net/stocks/charts/UBER/uber-technologies/net-income https://www.macrotrends.net/stocks/charts/UBER/uber-technolo...
- illiarian 4y ago
  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. :)
- chx 4y ago
  It always underpaid drivers. It exploited drivers not calculating car amortization costs and sometimes not even gas correctly. Also, people do not calculate the value of their time spent waiting (unpaid) and the cost to drive to the pick up (also unpaid). I guess Haraszti laughed his ass off when he learned of this bullshit. https://www.amazon.com/worker-workers-state-Piece-rates-Hungary/dp/0140219889 https://www.amazon.com/worker-workers-state-Piece-rates-Hung... He basically have proven the socialist state was paying factory workers only when their machine was actually working on a piece and then per the minute. And of course wrote a book criticizing the entire system on the side.
bhaney 4y ago
Completely skipping over the privacy concern doesn't seem like an amazing look
- tedivm 4y ago

mranton 4y ago

>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)

jedberg 4y ago
> 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.
- mranton 4y ago
  >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.
  - pwinnski 4y ago
    > 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."
chx 4y ago
> if you have 50 images on the page - we have to do 51 requests only (1 metadata for all images, How do you know the nearest peer has all the images at hand?
- mranton 4y ago
  to answer this question, I will write another article how we distribute cache among the Peers. Long story short: - we divide web cache in buckets - these buckets have different sizes - we know a list of files in every bucket - we know what buckets every Peer has

paxys 4y ago

1 is something every CDN in the world already deals with. The metadata system ultimately needs to be its own little CDN, and can achieve the same level of performance (e.g. by deploying at the edge) just without the bandwidth costs. 2 is definitely an issue. 3 is a maybe. There's definitely a model where people with access to cheap servers and bandwidth can get on board and not have to worry about the application-level details, finding customers, billing etc. 4 isn't an issue as long as you are selling the CDN specifically for website assets that don't need to have pretty URLs.

jedberg 4y ago
> 1 is something every CDN in the world already deals with. Not exactly. For a normal CDN, your webpage HTML directs the client directly to the CDN server, which in theory already has the object. Only if it doesn't have the object does it need to go get it, but there isn't an extra lookup. The CDN does it's direction magic via DNS or IP routing, not with double lookups.
jsnell 4y ago
1. None of the issues I listed affect traditional CDNs though. 3. Why would the people running a peer have cheaper access to servers and bandwidth than a company specializing in that business? Everything about this business should have huge economies of scale (buying hardware, system administration, transit/peering). The only situation where I can see a distributed model winning out is if the entity running the peer does not pay for resources but gets them with fraud or theft, e.g. paying for cloud servers with stolen credit cards.
- zamnos 4y ago
  It's a matter of locale. Having an entrepreneur in South Africa or Tibet hear about the money making opportunity, setting up a peer, and then paying them for it is better than flying there for a month to set up a business presence and figuring out all the local everythings. Akamai et al has already done this, and charge money commensurate with having done that. This group seems to be banking on someone in Kathmandu hearing about this opportunity and setting up a peer there.

x-complexity 4y ago

> 2. Privacy. Their threat model only addresses malicious peers changing content, not malicious peers trying to track users. I'm narrowing the scope around 'user tracking' specifically to 3rd parties, because 1st party user tracking is a requirement in order to perform some necessary functions (Providing accounts & user sessions, for example). In the current centralized CDN model (Cloudflare, AWS, Akamai, etc.), the 3rd party is made clear (those aforementioned companies), and their need to track users is documented on the provider's ToS. Likewise, reputational damage is accrued to the providers in question. In their proposed CDN model, there is no clear 3rd party, and so it must be defensively assumed that all of the data sent for requests is recorded at all times (The FBI Tor exit node problem). As a consequence, the minimal amount of request data can only be sent to these providers (IP address, content hash). Tor-like routing could be implemented to further disperse the requests from one IP address to multiple addresses, but now the monitoring problem's increased to the routers as well, on top of the additional latency introduced for said privacy. Mandating said routing into the protocol would make such tracks useless, as the IP address collected will roughly appear as random noise in the optimistic case. Personal opinion below However, it is likely that no technical solution provided would resolutely satisfy the question being asked.