Re: Real Media and M-Bone feeds

["Alex P. Rudnev" <alex () Relcom EU net>]

> > > Worse yet, it distracts from deployment of the real solution - cacheing.
>
> One needs pay close attention to the problem trying to be solved. I see it
> as being 2 cases:
>
> 1. Broadcast "live" or "real-time" data. This is what multicast is (should
>    be) really good at. Videoconferences with friendly geeks via some caching
>    mechanism would be awful at best, and still require more than one feed
>    from the source, or from some replication server (a la CUSeeMe).
In case of DENSE network, yes, in case of (sorry, forget right word) RARE
network, (SPARE?), it's almost the same. How much peopel over the world
use CUSeeeMe even withouth the packet replicators? And how much use MBONE?
Now compare...

> 2. "On-demand" data, such as your friendly neighborhood internet-movie
>    rental center. Don't laugh, I expect to see it in my lifetime. These
>    could be cached "close to home", assuming that there weren't some legal
>    issues with intercepting and storing data someone else paid for. Caching
>    is only good for asynchronous data likely to be requested numerous times
>    from various sources. i.e. I want to watch the same movie my neighbor
>    is, but I want to see it from the start, not pick up in the middle where
>    he is.
Just again - the CACHING and the MULTICASTING is two edges of the ONE
PROCESS - name it _CACHE AND REPLICATE THE DATA_. Why to build two
independent systems (caching and multicasting) instead of building one
common (CACHE-REPLICATE servers, with the _on the fly_ mechanism like
CISCO WWW-CPP protocol work), and with multicast on the far ends of the
data tree?

And again - MCAST is not scalable, IP address (classical or CIDR) is. 

> In case 1 above, as I stated, cache would not work well for several people
> in disparate locations trying to videoconference. How many 20Gb/s streams can
Where do you see 20Gb/s? I see the contents over the Internet with
16Kbit's, or (worst case) 80Kbit/s data streams. For the conference (when
it's not high quality movie watching) 80Kbit streams are more then
necessary.

100 * 80 = 8,000Kbit = 8Mbit. Image 2 - 3 level data replication - it
should be 200 - 300Kbit. Image MCAST on the far end, in the LAN's - no
bandwidth problems at all.

No one ask to use data replication for the WEB TV in your local provider
offer you it as the new TV system. But it's not INTERNET.

> Some suggested goals for multicast design*:
>
> . Ensure that data are replicated as close to the destination as possible.
Yep. It cause this to be useless for the ON-DEMAND data, and when there is
non-multicast networks between the data sor=urces and data listeners (i.e.
at 99% cases). 


> . Ensure that multicast routers not carry more topology data than are
>   absolutely necessary.
And this cause the routers to know EVERY DATA STREAM you have in your
media... And so on...

Please, understand - MCAST is not bad idea. MCAST has it's own fields. But
it should not became GLOBAL MULTIMEDIA TRANSPORT for the global INTERNET.

> . Ensure that the multicast system does not lend itself to DoS abuse, as
>   other methods of one-to-many data replication do.
>
> * I am a multicast newbie, and largely illiterate in current implementation,
> so don't laugh at my suggestions publicly, please. :-)




> -- 
> Those who do not understand Unix are condemned to reinvent it, poorly.
>                 -- Henry Spencer

Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)