> I strongly suspect that the combined time of engineering staff spent
> on deployment and development of mulitcasting won't be paid off by
> the supposed transport cost savings any time soon.
The problem is that everyone thinks that multicasting is
more complicated than it really is.
Jared, we (I and Vadim - it's amazing but we are far one from another but
support the same ideas) don't think multicasting is complex; but to build
stable, hacker's/free, well controlled multicast network is really the
complex (and unsolved yet) task.
And when thuch network will be (if) built, it cover only 10 - 15% of the
customers demand - only LIVE-MULTIMEDIA, while 90% of this demand is
_on-demand multimedia_ (hope I did not twisted my idea by the wrong
translation).
I here do not need multicasting now; I need to get a numerous multimedia
sources I have now in Internet, and made this sources available widely by
decreasyng the bandwidth they use in our uplinks. We have 1 - 2 - 3 live
events a week, and we have 10,000 - 100,000 on-demand sources - it's a
difference. And (more important) it's a better way to solve boths problems
at once than to follow _multicast_ idea blindly.
Multicast works well in the DENSE case - when you have a LAN network with
the 10 - 20 listeners; it's useless in the RARE network when 100 customers
listen everyone to his own stream. Moreover, multicast do nothining
(almost) in comparation with existing air broadcasting, it's not more than
one extra transport (and very complex transport - turn on your TV or your
radio-tuner - and you can listen to the Russion radio stations even from
the USA - now try the same by multicast); but ON-DEMAND streams provide
new feature for the customers - you can't call TV station and ask _show me
this animation_ - but RealVideo client can.
And the other idea I am talking again and again is very simple - there is
not PRINCIPIAL difference between caching, replication and multicasting -
it's the same process with some different tunings.
Alex
How many people would be interested in a presentation of
some sort on multicast, and deployment? The key here is education, and
the people who understand it tend to not be good at explaining it, nor
willing to spend the time educating the masses as necessary these days, as
their jobs have them working too many hours, or traveling enough.
Yes, you are right, the education is one example when you can found the
DENSE network.
You forgot to mention _feed-back in case of the video-conferencing_ - and
just again it's an example when existing multicasting have the strict
position. And... that's all, this is not big part of the internet's users.
People try and overthink a few too many things, and this I
think is one.
I'd be willing to do a multicasting BOF or somesort at the
next nanog if there is interest. Including real life deployment
examples, and practical applications for use.
> Worse yet, it distracts from deployment of the real solution - cacheing.
Multicasting is faster than disk. I'm not sure how caching
is the solution. Distributed content is also good.
To be strict, disk is faster than the multicasting. Then, in case of the
LIVE-STREAM, caching have 0 time-to-live and became the simple
replication. In case of the DENSE network, the best way to do replication
is multicasting. We don't deny such _edgge_ case, but it's only one state
of the caching machine.
