How do you put a TV station on the Mbone?
bicknell at ufp.org
Mon May 2 19:08:13 UTC 2011
In a message written on Mon, May 02, 2011 at 02:53:35PM -0400, Patrick W. Gilmore wrote:
> I'm not at all certain that this is a political problem. I believe it is more of a user need / want problem (which I guess you could classify as "layer > 7" if you want).
The users don't care if the content arrives via unicast, multicast,
ipv4, ipv6, or any other method. They just care when they click
on the link that it works.
I think the multicast issues have been largely discovered and solved
in small to medium deployments, but for some reason there is no
desire to work on them at Internet scale.
In small deployments the multicast is treated as unidirectional, with a
small number of fixed sources and lots of receivers. This takes out a
lot of technical obsticals to any-to-any multicast, and simplifies a lot
of the business relationship issues. Billing for multicast is seen as
"hard" for instance, and if anyone can dynamically put up or tear down
sessions I can see how that's true. But compare to a TV model which has
a fixed, 24x7 broadcaster and it is easy.
It's not a solution to every problem for sure. However it is a way to
bring 24x7 TV like service to the Internet _very_ efficiently. I'm sure
sites like cnn.com would rather pay to multicast their traffic to the
end user providers than to build the infrastructure for all the unicast
streams if the service was reliable and offered by all.
How do you get the business people to deal with it though? With
unicast every new viewer is more traffic, and traffic is a proxy
for revenue. Is it not the same problem as your electric company
not being incentivised to help you conserve? Why would companies
who make money selling megabits and gigabits want to give their
largest content customers a way to do things for a fraction of the
That I think is the real issue.
Leo Bicknell - bicknell at ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 826 bytes
Desc: not available
More information about the NANOG