Subject: Re: packet loss between mbone2.UU.Net & SanFrancisco.mci.net

From: Ross Finlayson <[email-masked]>
Date: Wed, 12 Feb 1997 13:05:42 -0800 (PST)

>>It's really a lot simpler: ISPs are basically "pipe mongers".  Multicast has
>>the potential to reduce the size (& thus cost) of the pipes that ISPs *buy*,
>>and could conceivably (by promoting interesting content) increase the number
>>(& perhaps size) of pipes that they sell.
>
>But what the ISP's mostly see is that it is likely to *decrease* the
>number of pipes they sell.  How many T3's does pointcast currently
>have, and how many would they need if they used multicast?  How about
>audionet.com?  How much of a loss is that for the ISP?  Why would they
>encourage such a move?

Yes, as long as the large multiple-unicast *senders* are happy to pay for
multiple T3s, their ISPs certainly have no incentive to tell them to start
using multicast.  (Right now I think PointCast is just hurrying to get their
IPO out the door before Wall St wakes up to the fact that their technology
model is fatally flawed :-)  But at some point these senders will realize
that in order to control their costs (& for their system to scale) they're
going to have to start providing a multicast feed as an *option* - i.e.,
alongside their regular unicast feeds.  At this point the ISPs for the
*receivers* will have an incentive to start carrying the multicast feed (in
order to reduce *their* costs), which will then 'encourage' their customers
to start using this, rather than unicast.

Now it's not obvious how this 'encouragement' (for receivers to switch to
multicast feeds) would actually work.  Perhaps the best solution would be to
have both a multicast and a unicast address associated with each such
service, and to have the application (e.g., "RealAudio player" or
equivalent) try the multicast feed first, then fall back to the unicast feed
if multicast is unavailable.  Of course, for this to work well, there should
be a way for the application to find out quickly whether or not the
multicast feed is available.  (I think that was one of the motivations
behind the 'heartbeat' hack that the Microsoft folks proposed at the last
MBONED WG meeting.)

        Ross.

---

From: Petri Helenius <[email-masked]>
Date: Wed, 12 Feb 1997 23:24:42 +0200 (EET)

> behind the 'heartbeat' hack that the Microsoft folks proposed at the last
I think the best way to handle this techically is to join the group
you want to receive the data from and see if data starts flowing, if
not record the fact and switch to unicast. After some time (like a
week or so?) repeat the discovery. This way when the network
infrastructure is upgraded you get applications to switch
automatically with minimal hassle to the users. And you also get the
maximum amount of switchovers.

In case of non-real-time application like pointcast, this would not
even hurt to try it every time the application is started.

Pete