There are some pretty interesting innovations coming down from deep packet inspection providers. In one case they're caching the data that users are serving via bittorrent and re-serving it to the second and future persons requesting it, basically giving users credit for sharing without saturating their upstreams and causing network problems.
It wouldn't surprise me if these products can do the same thing for downstream traffic as well.
Everything old is new again, it's like the 1990s proxy servers brought into the 2000s-2010s.
In this case, the "old" stuff you're talking about never really got "old". There's fundamentally not much of a difference between a proxy server and an edge overlay network fed with traffic redirection; in both cases, you're getting content from a middlebox.
Sure, conceptually. I didn't know of any big ISPs using proxies in the last 5-7 years, though, until the Comcast DPI fiasco happened.
I could well be out of the loop and not aware of any huge Squid or comparable installations, but I believed them to be archaic until recently because of how much faster commercial/service provider type WAN interfaces (DS-x, OC-x) were growing relative to consumer interfaces (DSL, cable). Of course FTTH (large bandwidth to each node) and wireless data (shared upstream + carrier optimizations for signal quality instead of bandwidth + physics) may turn this on it's head.
you think so? can you explain more? I am not looking at the theory of it, rather interested in working models where multicast is being used to deliver online content.
No, multicast cannot work on the Internet if the ISPs invest more effort. There remain fundamentally unresolved problems in Deering-model (IP-level) multicast.
The future of one-to-many content delivery is in edge delivery networks like Akamai. Maybe they'll use a (drastically simplified) multicast model internally, but that's an implementation detail.
AFAIK, turning on multicast would create many additional RIB/FIB entries in routers, possibly running routers out of RAM and requiring upgrades.
Also, because multicast duplicates packets, it could increase bandwidth usage in ways that are not easy to bill for, potentially increasing costs without increasing revenue. I don't think this is a real problem, but some people have cited it.
IP addresses (which we're running out of) address hosts. There are hundreds of millions of active full-time hosts.
Multicast addresses address content. How much more content is there than hosts? Do you really think it's feasible to give an IP address to every popular piece of content? YouTube allegedly gets almost 100,000 new videos per day.
The fact is, multicast hasn't been a success because it's simply not a good fit for the routing layer of the Internet. But edge overlay networks can build arbitrarily complex and interesting multicast service models on top of the Unicast Internet, and those overlays have been huge successes.
No, SSM reduces an explosively intractable routing problem to merely an intractable routing problem, by guaranteeing that video streams will only have a single sender (which is not even a win when you're competing with edge overlays).
You still need to have every upstream router maintain awareness of every piece of content being viewed by every downstream user.
Akamai --- or, more likely, Comcast and AT&T --- could accomplish the same thing without detonating your routing tables, just by adding servers and indirecting content with a traffic manager. Cringely is nuts.
In many cases P2P streaming would cause more congestion (especially upstream) than edge servers. However, P2P is cheaper than edge servers, especially for extremely bursty workloads like the inauguration or the Victoria's Secret fashion show.
Or is there another technology that could be really helpful for this type of event?