I've been thinking of this exact problem for a while and talking to
ISP's to see if anyone is doing anything about it. Don't appear to be.
My goal in the design below is to support real-time broadcast reception
by, potentially, very many receivers of near-realtime content. Radio,
TV, that sort of thing. Every startup dreams they can get their
'turn-key box' out there. Without MS and AOL money, that's not likely,
and they have their own political problems pulling it off. If it was
(defacto or IETF) standardized and expected of ISP's by their customers
and possibly presented as a profit center rather than a cost center, it
might just happen.
I propose creating a generic, open and open source, repeater/multicast
relay that 'anyone' could use and convincing ISP's to install it on
their networks behind their peer uplinks. I have a list of features and
architecture for this box, and it's fairly easy to create an efficient
cheap box, especially if it's not doing content management (i.e.
caching, store and forward). The hard part is getting through the
politics of ISPs, mixed interests (they charge for bandwidth so why
should they do something that lowers bandwidth used?), and competition
paying money from formerly bottomless pits (i.e. Akamai et al). The
latter obstacle should of course have less strength now.
Since I don't believe that anything proprietary is going to make it to
all the edges of the network to perform this repeater/multicast relay in
an open and economical way, I'm interested in creating an open-source
project with the right angle to incent ISP's, especially the large
ones. Done properly, this could make multimedia broadcasting viable
without clogging backbones.
I have one proposal that seems to have merit: charge someone (server or
client) for a fraction of the bandwidth saved but effectively created
close to the edge. In other words, a colocated server might create a
single stream of multimedia data for each connected peering repeater
that is then replicated on the other end of the peer connection to
connected repeaters or clients, optionally using multicasting within a
single ISP's network. The server may generate, in final delivery,
100Mbit or many gigabits, say, of data, but practically none at the
collocation point or backbone. This 'effective relayed bandwidth' could
then be charged for at a heavily discounted rate since it effectively
uses only cheap 'internal' bandwidth at each ISP rather than expensive
peering links. Since the bandwidth is really effectively generated near
users, users could also pay, directly or indirectly, for their own
multimedia bandwidth. This could also take into account popularity.
One person listening to a single stream is much less amortized at the
peering point and edge than 10,000 people watching CNN.
Note that this can all be done with least-common-denominator methods
including upward TCP connections only. There are a number of reasons
why raw multicast isn't suitable, beyond it's non-implementation.
Flaws? (Other than the obvious problem of getting everyone to agree to
implement it.)
What venue would you recommend for this? (IETF, SourceForge and the
like implementation first, partner with content providers, partner with
ISP(s), etc.)
sdw
Strata Rose Chalup wrote:
>
> I love talking to people about technology who know nothing about it.
> Like executive search firm guys who call me up to try to grill me about
> a hire made by an old employer, then change tactics to trying to sell
> me on a startup they have 3000 miles away.
>
> "No, this is incredible-- you won't believe it. Instead of sending
> a million copies of the message, you just multicast it! And it doesn't
> get hung up like all the other traffic, because it DOESN'T USE TCP/IP!"
>
> "Oh, so it uses a custom protocol? That'll be interesting to get ISP's
> to route for you."
>
> "No, no, it uses UDP."
>
> "But UDP runs on top of IP. It's subject to the same laws of physics."
>
> "But they're sending ONE COPY SIMULTANEOUSLY to all the millions of
> subscribers!"
>
> "Umm, are all these subscribers on the same ISP?"
>
> "No, they're in ISP's all over the world! And we can eliminate all these
> traffic bottlenecks!"
>
> "Just how do you ROUTE these UDP packets to all these people via multicast,
> especially since most ISPs aren't configured to multicast to all their
> clients?"
>
> "The ISP's will put in our turnkey box. We'll be making money for them!
> It's a no-brainer! It doesn't cost them anything!"
>
> ARGH....sometimes I think improving the breed should be done with directed
> education, such as that produced by the application of a large, heavily
> bound book forcibly to the occipital region. Repeat until student has no
> more questions.
>
> _SRC
>
> --
> ========================================================================
> Strata Rose Chalup [KF6NBZ] strata "@" virtual.net
> VirtualNet Consulting http://www.virtual.net/
> ** Project Management & Architecture for ISP/ASP Systems Integration **
> =========================================================================
-- sdw@lig.net http://sdw.st Stephen D. Williams 43392 Wayside Cir,Ashburn,VA 20147-4622 703-724-0118W 703-995-0407Fax Dec2000
This archive was generated by hypermail 2b29 : Fri Apr 27 2001 - 23:14:46 PDT