Date: Thu, 09 Nov 2000 17:42:31 -0500 From: "Louis A. Mamakos" <louie@TransSys.COM> To: Alan Clegg <alan@clegg.com> Cc: Tim Pozar <pozar@lns.com>, freebsd-multimedia@FreeBSD.ORG Subject: Re: RTP vs. HTTP as streaming protocol, SMIL Message-ID: <200011092242.eA9MgVG81806@whizzo.transsys.com> In-Reply-To: Your message of "Thu, 09 Nov 2000 16:38:30 EST." <20001109163830.A60099@diskfarm.firehouse.net> References: <Pine.BSF.4.21.0011090849440.281-100000@penguin.egd.igd.fhg.de> <20001109082322.DFDC07AEEB@defiant.vmunix.org> <20001109132515.A95823@lns.com> <20001109163830.A60099@diskfarm.firehouse.net>
next in thread | previous in thread | raw e-mail | index | archive | help
I can give you some perspective from my experience doing some of the early engineering and architecture work on UUNET's multicast infrastructure. It's been a year or two since I've had direct involvement, though. You can take it for what it's worth.. > I've been trying to find a service provider in my area (Silicon Valley > of the South) that understands and can provide Multicast. There are none > that are affordable. To get multicast, you have to go to Alternet or > Sprint, and both of them are *WAY* expensive. One of the barriers to widespread multicast deployment is to come up with a service model that's sustainable. That is, you don't go out of business if you have to do a lot of it. There's two or three major components to consider: - capital costs of the hardware. This probably isn't an issue at scale. - bandwidth costs. While the popular opinion is that multicast should be cheap, some analysis might lead to you other conclusions. Consider what the cost per megabit/sec of bandwidth is and how that relates to the price of the Internet service an ISP customer buys. Unicast traffic from a customer arrives at the edge of the network, it then transits some number of links/circuit miles, and is delivered to it's destination, or perhaps a peer of the ISP. For multicast, this is more complicated. If there are significant numbers of receivers, then the traffic is going to occupy capacity on *more* links than the same rate unicast traffic will. The cost per megabit/sec of multicast traffic is then higher than for unicast traffic. From an ISP's perspective, replicated unicast is a "scalable" solution from a business perspective (assuming the ISP operates with a positive margin on his products); the objective is to figure out how to survice success in carrying multicast traffic where the network makes more traffic on behalf the ISP's customer. - operational costs. Today, you need to know *way* too much about how multicast routing protocols work. How much time will the install engineer at the ISP going to need to spend to get your multicast service working? The trend should be that less and less human time be spent per new installation as well as for ongoing maintenance of any single customer's service. Right now, it's possible for mere mortals to get multicast running on an enterprise network. But the case of inter-domain multicast which requires nasty things like M-BGP, MSDP and crocks like that raise the bar considerably. There is hope, however, in this space -- single source multicast will considerably reduce the complexity and fragility of the current situation. > Anybody interested in starting a new provider that actually has clue? Good luck. The tough part is managing to both stay in business and survive success. At some point, you have to hire more and more staff and they can't all be uber-hackers. Doing something once is a dis-proof of non-existance and of essentially no value when you have to replicate the something a 100,000 times. Single-source multicast has the promise of making things more "plug-and-play". You can see some of these notions reflected in my remarks a week or so ago regarding the motivations of the PPPoE protocol design. Of course, fixing an engineering problem leaves you the business problem to contemplate and resolve. Louis Mamakos To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011092242.eA9MgVG81806>