Multicast is broken as an idea, period. Now, why won't we
just forget about it and spend our life doing something
useful instead?
--vadim
Now working for Alcatel 
Oui.
Multicast is broken as an idea, period. Now, why won't we
just forget about it and spend our life doing something
useful instead?
because, although it is getting less expensive quickly, transport costs
money. multicast promises to reduce that cost near sources.
this is a better fantasy than the qos smokers who think it will effectively
get more bits into the pipe.
randy
> just forget about it and spend our life doing something
> useful instead?because, although it is getting less expensive quickly, transport costs
money. multicast promises to reduce that cost near sources.
Wrong...
Multicast is just not more than one case of data caching on the fly. It
can be used for the local networks, just with the net of the media
replicators. In principle there is not big difference between multicast
and www caching except first is an example of the _real-time caching_ and
second is usially _store-and-forward_ caching.
This days we can see the weakness of the global-multicasting - and I think
it should be replaced by the media-caching servers (with the ability to
replicate data on the fly - in case of live media stream, and short or
long tome _store-and-forward_ in case of Video-on-demand stream) - and
with just this multicasting on the very end of the data tree. But an
attempts to build over-the-world multicast network - brr... it's possible
(if you should dig some mountain every day, you'll build a tunnel at last;
but may be it's easy to run this mountain over?).
And - your NANOG forum is the excellent example. RealVideo streaming work
fine; Multicast don't work at all; why do you try to use weak schema
instead of the strong one? No enougph bandwidth - install stream
replicators inb the key points; build _replication on the fly_ schemas
(such as CCP for the www caching on the fly), etc. No, even with all
attempts Cisco and some other are trying this days - multicast is more
dead than alive. I can get 10,000 multimedia sources by RealVideo or
StreamVideo - and I can't get nothing usefull by multicast. If I could
install RV-cache engine (cache on the fly) - I should choose this
solution.
this is a better fantasy than the qos smokers who think it will effectively
get more bits into the pipe.randy
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)
}
}> > just forget about it and spend our life doing something
}> > useful instead?
}>
}> because, although it is getting less expensive quickly, transport costs
}> money. multicast promises to reduce that cost near sources.
}Wrong...
}
}Multicast is just not more than one case of data caching on the fly. It
}can be used for the local networks, just with the net of the media
}replicators. In principle there is not big difference between multicast
}and www caching except first is an example of the _real-time caching_ and
}second is usially _store-and-forward_ caching.
It it really comparable to caching? I see multicasting as more of a
traffic reduction, rather than a cache.
}This days we can see the weakness of the global-multicasting - and I think
}it should be replaced by the media-caching servers (with the ability to
}replicate data on the fly - in case of live media stream, and short or
}long tome _store-and-forward_ in case of Video-on-demand stream) - and
}with just this multicasting on the very end of the data tree. But an
}attempts to build over-the-world multicast network - brr... it's possible
}(if you should dig some mountain every day, you'll build a tunnel at last;
}but may be it's easy to run this mountain over?).
Your model would work, but it requires a LOT more coordination and
cooperation than even multicast requires. Are you sugesting that networks
implement machines that sniff into the data, identify those streams,
intercept them, and then coordinate with the streams' sources to stop
sending the unicasts behind the cache, and send the stream to the cache
only? Or will your new machine simply "spoof" the source? If the latter,
then you haven't told the sender to reduce the traffic.
You mentioned your doubt of building an over-the-world multicast
network... but what you are sugesting seems to be an over-the-world
caching mechanism. If we are going to build an over-the-world anything,
why not build on the IP model, which is already over-the-world?
The whole reason for multicast is to reduce the traffic at the source, not
necessarily just then receivers. And the concept behind ip multicast is
to replicate as closely as possible the IP model - send trafic to an IP
address, and let the layer 3 devices forward the packet to the right
shared-media networks as required.
}And - your NANOG forum is the excellent example. RealVideo streaming work
}fine; Multicast don't work at all; why do you try to use weak schema
}instead of the strong one? No enougph bandwidth - install stream
}replicators inb the key points; build _replication on the fly_ schemas
}(such as CCP for the www caching on the fly), etc. No, even with all
}attempts Cisco and some other are trying this days - multicast is more
}dead than alive. I can get 10,000 multimedia sources by RealVideo or
}StreamVideo - and I can't get nothing usefull by multicast. If I could
}install RV-cache engine (cache on the fly) - I should choose this
}solution.
You can get a lot more software for Windows, too, but that doesn't make it
the right solution all the time. How much software was available for
Linux just two years ago? Market share is a poor measurement of the
quality and capability of a solution.
-andy
}Multicast is just not more than one case of data caching on the fly. It
}can be used for the local networks, just with the net of the media
}replicators. In principle there is not big difference between multicast
}and www caching except first is an example of the _real-time caching_ and
}second is usially _store-and-forward_ caching.It it really comparable to caching? I see multicasting as more of a
traffic reduction, rather than a cache.
Strictly saying, it's THE SAME.
The cache engine can - STORE traffic for some time, and replicate it. If
it can only replicate traffic on the fly (store time is 0), it works like
MultiCast. If it can only replicate data after all data was read, it works
like WWW cache. If it can do boths, it looks like un-existing RealMedia
cache engine which should replicate live traffic (may be converting it to
the multicast if it's necessary) and store (and reproduce at request)
on-demand traffic (with possible multicasting if two requests are coming
in the same time).
}replicate data on the fly - in case of live media stream, and short or
}long tome _store-and-forward_ in case of Video-on-demand stream) - and
}with just this multicasting on the very end of the data tree. But an
}attempts to build over-the-world multicast network - brr... it's possible
}(if you should dig some mountain every day, you'll build a tunnel at last;
}but may be it's easy to run this mountain over?).Your model would work, but it requires a LOT more coordination and
cooperation than even multicast requires. Are you sugesting that networks
Why? There exist Cisco WEB cache engine which work _on the fly_; if (for
example_) this box could work for the RealVideo traffic (even withouth the
multicasting) and if 10 - 20 greatest ISP install such boxes - this allow
to increase the number of people who can ask Vide-on-demand withouth
throughput problems dramatically. Note - this do not need political
decisions AT ALL.
Then, more than 70 - 90% of the multimedia content this days is
_on-demand_ content. I don't need live CNN, I ask _last news review_ from
CNN; I have asked video topics about the Japan Radioactive Pollution last
days; I'd like to hear last NANOG sessions just now (note - NOT LIVE but
LAST). Multicast can't help here at all; data caching can help 100%.
Compare the Multicast content and RealVideo content internet have this
days.
And think about new hacker's attacks became possible just when you allow
multicast to cross AS boundaries...
implement machines that sniff into the data, identify those streams,
intercept them, and then coordinate with the streams' sources to stop
sending the unicasts behind the cache, and send the stream to the cache
only? Or will your new machine simply "spoof" the source? If the latter,
You just describe how WWW CACHE engine does work. What's the difference
between WWW and RealVideo? Not any - request (like SIP protocol) opens
data stream; request can be catched easily, transparently for the
customer.
Nothing new except existing methods.
then you haven't told the sender to reduce the traffic.
You mentioned your doubt of building an over-the-world multicast
network... but what you are sugesting seems to be an over-the-world
caching mechanism. If we are going to build an over-the-world anything,
why not build on the IP model, which is already over-the-world?
There is a huge difference. Caching can be done locally first, over the
EXISTING content, EXISTING RealMedis servers, Existing client programs -
it transparently reduce the traffic, not more. Multicast can't work if it
was not built over the whole world.
The whole reason for multicast is to reduce the traffic at the source, not
May be; but the _on demand_ sources can keep this days huge amount of the
traffic. The problem is _how to deliver it_ and _why just the same video
clip should run through undersea cable 100 times/day instead of been
caching on the other end.
necessarily just then receivers. And the concept behind ip multicast is
to replicate as closely as possible the IP model - send trafic to an IP
address, and let the layer 3 devices forward the packet to the right
shared-media networks as required.
Yes, no doubt.
And now - compare IP packets with the SMTP message. This message contain
the LIST of all receivers when it was sent - and it allow it to be
replicated authomatically. But in case of Video and Internet, the sender
could not write THE LIST of RECEIVERS (btw, WHY not? It could be done by
IP options withouth extra problems, or by the SOURCE-ROUTING) and use
reverse-paths calculations just as absolutely other address schema
instead.
I am not saying _multicast concept was absolutely wrong_, but I'd like to
aware from blend trusting to the multicast. Note - internet have a lot of
multimedia this days, but it's mostly ON-DEMAND multimedia. Note, LIVE
multimedia just exist for a 10 - 20 years - it is usial TV; but it can't
solve the ON-DEMAND problem; note - multicasting can't solve ON-DEMAND
problem, it's just one more TV.
}And - your NANOG forum is the excellent example. RealVideo streaming work
}fine; Multicast don't work at all; why do you try to use weak schema
}instead of the strong one? No enougph bandwidth - install stream
}replicators inb the key points; build _replication on the fly_ schemas
}(such as CCP for the www caching on the fly), etc. No, even with all
}attempts Cisco and some other are trying this days - multicast is more
}dead than alive. I can get 10,000 multimedia sources by RealVideo or
}StreamVideo - and I can't get nothing usefull by multicast. If I could
}install RV-cache engine (cache on the fly) - I should choose this
}solution.You can get a lot more software for Windows, too, but that doesn't make it
the right solution all the time. How much software was available for
Linux just two years ago? Market share is a poor measurement of the
quality and capability of a solution.
I know, and I don't deny everything you was saying. But most of the
multimedia sources I want to watch can't be improved by multicasting at
all; no security or stability problems was solved at all, and the very
roots of the multicasting was in the live conferencing, not in the
customer's demands. This cause me to be very sceptical about multicasting.
-andy
--
Andy McConnell IP Operations Manager andym@ntt.net
NTT America Network and IP Service Division +1 408 873 3757
e$B??8~N}e(B e$B0BEHN6e(B NTTe$B%"%a%j%+e(BIPe$B%*%Z%l!<%7%g%sC4Ev2]D9e(B"What right does Congress have to go around making laws just because they
deem it necessary?"
- M. Barry, Mayor of Washington, DC
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)
Caching doesn't work for live content.
D.
From: Darin Divinia <ddivinia@broadcast.com>
To: Andy McConnell <andym@ntt.net>, Alex P. Rudnev <alex@Relcom.EU.net>
Cc: Randy Bush <randy@psg.com>, Vadim Antonov <avg@kotovnik.com>,
nanog@merit.edu
Subject: Re: Real Media and M-Bone feeds
Caching doesn't work for live content.
Caching work for the live content - it became REPLICATION.
If you have cache engine which can:
- catch request,
- ask the data source about the data stream itself
- store the data stream, just as replicate it to those who requested it
- reproduce the data stream from the cache
Then you have a few cases:
(1) store time - 0, all data are replicated on the fly - live streams,
multicasting is one of the ways to do replication;
(2) store time - long, can't replicate data at all (every request get it's
own data stream) - just existing WWW cache engine
(3) store time - middle (few hours), the requested are delayed a little in
attempts to merge a few Media-On-Demand requests into the same answer -
MultiMedia cache.
I have pointed here - the customers demand is (from my point of view, you
can disagree) more ON-DEMAND multimedia content. Multicasting does nothing
with it. Multicasting does nothing about existing multimedia content.
Multicasting need in fact to build new interaction schemas between an ISP
over the world. That's why I don't think it's the best solution for the
multimedia demand we have from the customers this days.
On the other hand, if you have a dense multimedia streams in some network
(for example, Internet TV delivered by ADSL in the local region) and it's
just in the one ISP - multicast can be used as ONE of the delivering
methods. For now, it exist more as an independent address schema.
Alex Roudnev.
> D. > >
>
>
>}
>}> > just forget about it and spend our life doing something
>}> > useful instead?
>}>
>}> because, although it is getting less expensive quickly, transport costs
>}> money. multicast promises to reduce that cost near sources.
>}Wrong...
>}
>}Multicast is just not more than one case of data caching on the fly. It
>}can be used for the local networks, just with the net of the media
>}replicators. In principle there is not big difference between multicast
>}and www caching except first is an example of the _real-time caching_ and
>}second is usially _store-and-forward_ caching.
>
>It it really comparable to caching? I see multicasting as more of a
>traffic reduction, rather than a cache.
>
>}This days we can see the weakness of the global-multicasting - and I think
>}it should be replaced by the media-caching servers (with the ability to
>}replicate data on the fly - in case of live media stream, and short or
>}long tome _store-and-forward_ in case of Video-on-demand stream) - and
>}with just this multicasting on the very end of the data tree. But an
>}attempts to build over-the-world multicast network - brr... it's possible
>}(if you should dig some mountain every day, you'll build a tunnel at last;
>}but may be it's easy to run this mountain over?).
>
>Your model would work, but it requires a LOT more coordination and
>cooperation than even multicast requires. Are you sugesting that networks
>implement machines that sniff into the data, identify those streams,
>intercept them, and then coordinate with the streams' sources to stop
>sending the unicasts behind the cache, and send the stream to the cache
>only? Or will your new machine simply "spoof" the source? If the latter,
>then you haven't told the sender to reduce the traffic.
>
>You mentioned your doubt of building an over-the-world multicast
>network... but what you are sugesting seems to be an over-the-world
>caching mechanism. If we are going to build an over-the-world anything,
>why not build on the IP model, which is already over-the-world?
>
>The whole reason for multicast is to reduce the traffic at the source, not
>necessarily just then receivers. And the concept behind ip multicast is
>to replicate as closely as possible the IP model - send trafic to an IP
>address, and let the layer 3 devices forward the packet to the right
>shared-media networks as required.
>
>}And - your NANOG forum is the excellent example. RealVideo streaming work
>}fine; Multicast don't work at all; why do you try to use weak schema
>}instead of the strong one? No enougph bandwidth - install stream
>}replicators inb the key points; build _replication on the fly_ schemas
>}(such as CCP for the www caching on the fly), etc. No, even with all
>}attempts Cisco and some other are trying this days - multicast is more
>}dead than alive. I can get 10,000 multimedia sources by RealVideo or
>}StreamVideo - and I can't get nothing usefull by multicast. If I could
>}install RV-cache engine (cache on the fly) - I should choose this
>}solution.
>
>You can get a lot more software for Windows, too, but that doesn't make it
>the right solution all the time. How much software was available for
>Linux just two years ago? Market share is a poor measurement of the
>quality and capability of a solution.
>
>-andy
>
>--
>Andy McConnell IP Operations Manager andym@ntt.net
>NTT America Network and IP Service Division +1 408 873 3757
>e$B??8~N}e(B e$B0BEHN6e(B NTTe$B%"%a%j%+e(BIPe$B%*%Z%l!<%7%g%sC4Ev2]D9e(B
>
>"What right does Congress have to go around making laws just because they
>deem it necessary?"
> - M. Barry, Mayor of Washington, DC
>
>
>
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)
With respect, the problems weren't all with the multicast. Many of the
problems had to do with SNAFU.
Merit had a fire at one of our computing centers two days prior to NANOG.
Service restoration for Merit had taken precedence and we had insufficient
time to properly test our broadcast environments under Real and MBONE.
Add to this coordination problems for MBONE in general and it was
amazing that we got it working at all. The only thing I can say is that
next time, we'll do better. (Unless the fire demons conspire against us
again.)
FWIW, we also had distribution issues with Real due to licensing and
available bandwidth. In order for this to scale better the next time,
we'll have to make arrangements for multiple servers around the Internet
to handle the load appropriately. Theoretically (and only speaking
as such - I'm inexperienced with MBONE and multicast in general),
Multicast should scale better. I'll leave that discussion to those
who _do_ have the experience. (And hopefully I'll be able to help
contribute to the data set at the next NANOG with a properly working
setup.)
So, please don't use NANOG as an example of the failure of multicast.
Such evaluations should be done with all other things being equal.
I'd like to thank Nortel, Mlink and CW for all their help in getting
things done as well as they were under the circumstances.