Community Page
- techliberation.com/ Jump to website »
-
Subscribe -
Community
-
Top Commenters
-
Popular Threads
-
Recent Comments
- Steve R. -- you might want to read the Web Site User Agreement for my web site http://zgp.org/~dmarti/meta/tos/ and do something similar. (I was thinking of something like "by reading my blog...
- Incredibly hollow post, contracts of adhesion are designed to unilaterally "protect" the seller by "restricting" (depriving) the consumer of their rights. To assert that we...
- Why don't more proprietary software vendors use a common license? The proprietary EULAs mostly say the same things -- couldn't the BSA or somebody issue a standard one?
- Twitter as we know it was built for about $15-20 million. Google lasted almost a year on $100,000 before taking over the world with $25 million of investor money. This is highway robbery, you could...
- I think the news people are in a "damned if you do, damned if you don't" bind over Google's indexing and summarizing of their work. Allowing it to be indexed gets them a little...
3 years ago
3 years ago
3 years ago
#1. multicast theoretically only works if all 'consumers' of the stream are consuming at roughly the same time (and even then, the technical hurdles are significant). This is because multicast doesn't cache the bits for later use. It isn't a good solution for users who want to view content on-demand.
#2. Akamai's Edgecast solution does indeed address the shortcomings of multicast, by caching data at each node. The inner-workings of distribution among these nodes is not publicly known in detail, but your assumptions are probably not far off.
#3. Here's the big technical error: you claim that a p2p model is less efficient than Akamai. You are wrong for several reasons:
a) Akamai has to physically place nodes, and the distribution of those nodes must match demand. This is problematic for several reasons. Suppose the content provider assumes that 10 million users in the US will download a copy of their content, and that these users will be more or less uniformly distributed throughout the country. But then, to their surprise, 8 million people in Arkansas try to download the show, and only 1 million in the rest of the country. The Arkansas residents will be starved for capacity (resulting in millions of failed downloads), while the rest of the country will be overserved with capacity. With a p2p distribution system, each consumer becomes a provider, and capacity automatically moves to where it is needed. This is commonly referred to as 'swarming', and is what happens with products like BitTorrent and RedSwoosh. Because there is a 1-to-1 relationship to consuming/providing content, capacity is only limited by total network capacity -- you can't beat that for performance!
b) You claim that ISPs (and Akamai) have better knowledge of physical topologies, and can thus better place caching nodes in the topology. Yet physical topology is irrelevant. This is counterintuitive, but the only metric that matters in networking is current network performance. Physical proximity or channel capacity doesn't matter, because performance (bps) is variable. Even if nodeA is physically closer to me and the connection to it, pipeA, has higher capacity, it does me no good to prefer it over further away nodeB and lower capacity pipeB if pipeA is currently congested and pipeB is not.
c) Cost and efficiencies. This derives a bit from a) and b), but the reason Akamai will always be more expensive to run than BitTorrent (even if all bandwidth were 100% free) is that you have to have an army of Akamai installations and support staff to service those 18,000 nodes, and the staff has to be distributed around the globe. Even if your support army works for free, you still have to pay for electricity, physical facilities, and bandwidth. Spread your content with BitTorrent instead, and you can get rid of all that staff and all those physical installations.
In short, I'd sum up centralized, hierarchical distribution strategies as analgous to centrally planned, hierarchical economies. The Akamai design is the design of a network communist, centrally planned by committee, politburo, or dictator -- and no matter how well it is planned, it can never respond to changing market forces as well as a free market can. (BTW, that isn't a criticism of Akamai as a capitalist business or even as an engineering design -- Akamai continues to pull in wonderful revenues, and at the time it was designed, it was revolutionary. It's just that Adam Smith hadn't come along yet...)
3 years ago
However, I still think that peer-to-peer applications are relatively wasteful of bandwidth. It's true that a peer-to-peer application doesn't need to know the details of network topology to get its own packets from point A to point B. However, the fastest route for a particular P2P client isn't necessarily the same as the most cost-efficient way of getting content.
An important factor is the relative costs of backbone bandwidth and storage. If storage is cheap and backbone bandwidth is expensive, the ISP may find they can save money by caching more content locally.
ISP-run caches have the advantage that they're available 24/7. With a P2P scheme, the last person on my local network to download a particular file may not be on the network any more, requiring that it be re-downloaded from the backbone. ISP-run caches might also have a greater ability to pre-stock the cache with content during periods of low bandwidth demand. ABC might, for example, load ISP caches up with the new episode of Desperate Housewives early in the morning for release the following evening.
Obviously this isn't a binary issue. Both P2P and commercial caching will be important for the foreseeable future, and I may very well be overestimating the advantages of the latter. But I think it's pretty likely that caching will be the superior strategy for at least a few applications, and if so, it's important that the legal system doesn't interfere with experimentation.
3 years ago
I'm not against ISP caching. Certainly, for many types of traffic, it helps. But I maintain that caching data at the edge of the network a priori as a scheme for distributing content with the goal of reducing costs is a much less-cost-effective solution than using adaptive p2p networks. If you aren't convinced of this by a simple cost analysis of what you have to pay to get Akamai (or one of its competitors) to distribute your content vs. what you have to pay to use BitTorrent, RedSwoosh, or one of its competitors, I'm not sure that anything I say will convince you. But I thought it might be useful to describe the technical reasons why the cost structure for centralized, hierarchical network distribution channels will always be much greater than that of democratic on-demand cooperative swarming distribution.
One of these technicalities is cache size and cache replacement policies. As long as the only thing we are talking about is episodes of Desperate Housewives, it is easy for ISPs or Akamai to provision enough storage resources at the nodes on the edge of the network to cache this content. But we know that users will want more than just Desperate Housewives. In fact, we know that traffic in today's p2p filesharing networks follows the long-tail distribution, and that the total amount of bytes consumed by the long tail dwarfs that of the blockbuster spike. So you can set up a cache of finite size at the edge, and you can cache the most popular content, but you can't possibly ever hope to have enough storage to contain the majority of traffic that will be generated by the long tail.
So if you are an ISP, what do you do for all that long-tail content? You hope that your users are using something like BitTorrent, which will prefer to download from peers that are near because those peers will, by their very nature, be able to provide the best service. And, lucky for you, those peers that are closest will be on your own network, so you won't be incurring costs going out to the backbone (just as if they had a cache on your own network).
Yes, if no one on your local network is sharing a copy of a particular file, your users will have to go out to the backbone (at least once). But that's the absolute best you can do. Period. Even if you have a cache, if none of your users have accessed that particular file recently, it will get expunged from the cache soon anyway (because no matter how big, your cache is finite, and because the long tail causes a lot of expunging).
How about this: pretend your ISP cache is a distributed cache. Now, think of the nodes of that distributed cache residing not on your own servers in your data center, but out on your customer's PCs. It's still a local cache. Only its bigger, smarter, cheaper, and more efficient than your centralized ISP cache could ever be. And that is why, sooner or later, the 'push data to edge node caches' model is doomed.
I hope I'm not derailing the discussion, and I'm not sure if any of this affects your core point about net neutrality, but I really feel strongly about p2p as an incredibly robust architecture (the fact that it is most commonly associated with pirating media is a shame).
3 years ago
You've obviously thought about this question more than I have, as you make a very good argument. I'll have to give this some more thought, but right now I find your argument pretty convincing. Thanks for commenting.
3 years ago
3 years ago
3 years ago
You put the stress on require, I'd put it on _allowed to_. Just because they have the right to charge to cross their network doesn't mean they will. I know... I know... I've read all the doom and gloom reports too. But a far more likely model is the one where sites are given the option to pay for priority service. If they pay, they are given priority bandwidth and their data travels with increased reliability. If they don't pay, their data travels with the same speed and reliability it travels with now. Sure, they look slower because they don't pay, but it's only a relative slowness.
The real issue is whether the ISPs will be able to keep up with the demand for priority bandwidth, and what they plan to do if they can't.
3 years ago
3 years ago
2 years ago
2 years ago
2 years ago
2 years ago