How do you put a TV station on the Mbone? (was: Royal Wedding...)

Mailman List Mirror (Read Only)
21

Why would they bill someone for a service they are already providing?

So the first user in a router tunes to a multicast stream. Consumption
for the ISP and all the routers in the chain to the source: same as if
it were a unicast stream. Then a second user tunes to a multicast
stream. Cost for the ISP: zero.

So 5000 users connect each to a different multicast source. It is the
same as if they all used unicast. The utilization can never be
worse than a unicast-only network.

So maybe I'm oversimplifying, but I fail to see a problem, only an
artificial one created for the sake of it. Other than the potencial CPU
load of the routing protocol, I even fail to see the commercial value of
not providing multicast.

22

Simple.

Go get yourself an encoder - VBrick, Envivio, Tandberg, etc, etc - there's
plenty out there, take your pick. That'll take video + audio as an input, and
output the encoded video (typically MPEG-2 or H.264 in an MPEG-2 transport
stream) as multicast.

Hook that into your favourite ISP that supports global multicast (several of
the tier-1's do), and you're all done.

Simon

23

Yup: that's what the Content Industry does: invents problems just
for the sake of it.

Cheers,
-- jra

24

Really. It's that trivial? Ok. Cool. Anyone know if Road Runner's one of
those? And how do viewers watch it?

Cheers,
-- jra

25

That would, indeed, be awesome; when everyone in my office was listening to
the royal wedding, there would be a *much* higher chance of them all being
in sync.

Cheers,
-- jra

26

Great. So, as I asked earlier (as yet unanswered):

I have in my hand an NTSC video cable and an XLR with audio. How do I
hook
that to the mbone? :slight_smile:

Cheers,
-- jra

Might want to ask the folks at Silicon Valley Linux Users group, they used to broadcast their meetings on the mbone, not sure if they do anymore.

Maybe use google a little:

http://sitka.triumf.ca/pub/mbone/uclambone-faq.html

You should be able to find enough to get you started.

27

> Imagine: multicast internet radio! Awesome!

That would, indeed, be awesome; when everyone in my office was
listening to
the royal wedding, there would be a *much* higher chance of them all
being
in sync.

Cheers,
-- jra

Exactly. If more people/networks took advantage of multicast, it would greatly reduce the bandwidth requirements, particularly for live events. If there were 50 people listening to a popular radio show or watching a live TV event in your office, for example, there would be only one feed crossing the wire into your office. And only one feed crossing into your provider's network.

I have *no* idea why applications developers have not been more interested in this, particularly with radio and television stations providing live streams on the net. It is absolutely a waste of resources to have a separate stream for each listener of a live event.

The mobile networks are more up to speed in this regard. Verizon Vcast is probably the largest implementation that I know of.

28

1) As a consumer network (enterprise, home) - that case is VERY rare. 50 people consuming it at your house? Or at the office consuming the same feed? (even at a 10k employee company, the rate of that is fairly low, particularly on the same leg of the network - I'd love to see some statistics that prove me wrong). The amount of work that goes into supporting and maintaining this is much higher than the return I'd get from it. Even assuming the upstreams supported it.

2) as a content provider, there's a lot of extra work involved to maintain this with my upstreams, and every mid-stream between me at the consumer networks. I require specialists in multicast (comparatively speaking unicast specialists are a dime a dozen) and I have to fight a lot of politics with the upstreams, and I -still- have to support the unicast models so the folks who can't consume multicast can see my content.

3) as an a midstream network provider I have almost no motivation to support this. Sure, my network usage would be reduced - but I (more or less simplified here, but) make my living on each bit of traffic I carry - if I offered a way for providers and consumers to reduce their traffic, that would reduce the amount they pay me. Win for them, lose for me.

the fact of the matter is that until multicast or it's like -doesn't- require massive end-to-end support (and frequently configuration to support each stream), there won't be heavy use of it. When I can turn up a multicast stream as easily as I can turn up a unicast stream, there is -still- a absolute lack of client-side software to recieve and playback the streams, and very limited support for broadcasting the streams.

...david (one time multicast specialist supporting a 200,000 seat 4 channel multicast infrastructure, so I'm fully aware of what magic is really involved in maintaining it across divergent networks that -WE- owned (or could exercise control of). before that streaming 40Gb/s (~200 channels of unicast video for general consumers + on demand streams)

29

From: "david raistrick" <drais@icantclick.org>

1) As a consumer network (enterprise, home) - that case is VERY rare.
50 people consuming it at your house? Or at the office consuming the same
feed? (even at a 10k employee company, the rate of that is fairly low,
particularly on the same leg of the network - I'd love to see some
statistics that prove me wrong). The amount of work that goes into
supporting and maintaining this is much higher than the return I'd get
from it. Even assuming the upstreams supported it.

I'd expect it to be fairly common at colleges; possibly in companies,
depending on the content being watched: live news events are the most
common example -- igmp aware viewer clients (which would bias towaards
this by showing the already running feeds) would also help.

2) as a content provider, there's a lot of extra work involved towards
maintain this with my upstreams, and every mid-stream between me at the
consumer networks. I require specialists in multicast (comparatively speaking
unicast specialists are a dime a dozen) and I have to fight a lot of
politics with the upstreams, and I -still- have to support the unicast
models so the folks who can't consume multicast can see my content.

Is it still this fragile in 2011?

3) as an a midstream network provider I have almost no motivation to
support this. Sure, my network usage would be reduced - but I (more or
less simplified here, but) make my living on each bit of traffic I carry -
if I offered a way for providers and consumers to reduce their traffic,
that would reduce the amount they pay me. Win for them, lose for me.

americafree.tv has a list, compiled (I think) by Marhsall Eubanks, that
lists ISPs and backbones with a formal positive position on this.

Be fun to put you two in a room together. :slight_smile:

the fact of the matter is that until multicast or it's like -doesn't-
require massive end-to-end support (and frequently configuration to
support each stream), there won't be heavy use of it. When I can turn
up a multicast stream as easily as I can turn up a unicast stream,
there is -still- a absolute lack of client-side software to recieve and
playback the streams, and very limited support for broadcasting the streams.

Clearly, there's not an *absolute* lack, or people wouldn't be using it
for anything anywhere ever, which they demonstrably are.

I should think that given Flowplayer, there's a pretty good platform for
implementing such a player in the environment in which program providers
would want to use it... though I'm not intimately familiar with its code.

...david (one time multicast specialist supporting a 200,000 seat 4
channel multicast infrastructure, so I'm fully aware of what magic is
really involved in maintaining it across divergent networks that -WE-
owned (or could exercise control of). before that streaming 40Gb/s
(~200 channels of unicast video for general consumers + on demand streams)

And you haven't written the O'Reilly book yet... why? :slight_smile:

Thanks for the input, David.

Cheers,
-- jra

30

I'd expect it to be fairly common at colleges; possibly in companies,

ok, colleges I can buy.

Is it still this fragile in 2011?

It was in 2009, anyway.

And you haven't written the O'Reilly book yet... why? :slight_smile:

Because it's not an experience I care to repeat. :wink:

Today, I make video games. MUCH more fun! (who knew, content CAN be fun)

31

That reminds me of 9/11. When the tragic event unfolded, we sat in the
office. News made the rounds verbally, and people started looking for
streaming services at their personal desks (no TVs around). People
pretty quickly gave up trying to find streams and news portals which were
actually working fine and the crowd gathering behind me watching over my
shoulder became bigger and bigger.

Why? Because I was in the fortunate position of being able to watch an
Mbone multicast stream of some news TV broadcaster... cannot remember
wether it was CNN or BBC or someone else entirely. Back then, a collegue
was playing around with IP multicast and my desktop machine had connectivity
to his Mbone-connected playground. :slight_smile:

IP multicast was the only way for us to see what happened, live.
Unicast failed miserably.

Best regards,
Daniel

32

Daniel,

> Imagine: multicast internet radio! Awesome!

That would, indeed, be awesome; when everyone in my office was listening to
the royal wedding, there would be a *much* higher chance of them all being
in sync.

That reminds me of 9/11. When the tragic event unfolded, we sat in the
office. News made the rounds verbally, and people started looking for
streaming services at their personal desks (no TVs around). People
pretty quickly gave up trying to find streams and news portals which were
actually working fine and the crowd gathering behind me watching over my
shoulder became bigger and bigger.

Why? Because I was in the fortunate position of being able to watch an
Mbone multicast stream of some news TV broadcaster... cannot remember
wether it was CNN or BBC or someone else entirely. Back then, a collegue
was playing around with IP multicast and my desktop machine had connectivity
to his Mbone-connected playground. :slight_smile:

IP multicast was the only way for us to see what happened, live.
Unicast failed miserably.

+10

I've been meaning to write something similar. Multicast infrastructure
in place absolutely and certainly has a role to play in
"humanity-wide" events.
Also, having a 'free' distribution channel for those moving images
carrying such licensing that it does not matter how many eyeballs see
them, could be valuable as well.

I made sure to get this capability in the network I worked on last.

Cheers,
Martin

33

Delivering multicast to end users is fundamentally not hard. The
biggest issue seems to be with residential CPE (pretty much the same
problem as IPv6, really).

Well, more than that, since I don't really want my DSL pipe saturated
with TV that I'm not watching, you need some way for the CPE to tell
the ISP "send me stream N"

There are CPEs that do this, but some don't do it on a public IP network.

Additionally, considering the state of the home CPE market and how horrible it is, I doubt it will get better anytime soon. You have to look no further than the copious numbers of "IPv6 Ready" devices on the shelves in stores today. Oh, and the fact that the NAT on the v4 side breaks multicast.

I suppose with some sort of spanning three thing it'd even be posssible
to do that at multuple levels, so the streams are only fed to people
who have clients for it.

This is what IGMP+PIM already do, sometimes with layer-2 support from switches, sometimes not, all depends on your topology.

- Jared

34

I think this is sadly the truth. There are some problems that can be solved by multicast, but I've seen the number of customer requests for v4 multicast go by the wayside over the years. The only people that are generally interested are the conference venues for technical things, e.g.: RIPE, ARIN/NANOG, APRICOT, etc.

Plus, conferences like NANOG have beamed the video back to some other site for fanout as well, for both unicast and multicast.

The problems at Layer7 and below are solvable with market forces. They're all 8/9 issues, about the content providers wanting to be paid-per-subscriber/viewer. They don't want to know how few people are actually tuned in at that moment in some cases. I'm sure they want to be paid some fraction of that cost that goes to your TV Transport conduit provider.

- Jared

(who buys and downloads shows, and pays nothing for others as they come OTA "free")

35

I'll say that today with some providers offering streaming to customers iPad and other types of devices, the problem isn't the capacity to the home, nor is it really a concern for them. It clearly doesn't matter if it's switched video, IPTV, or some RF.

All the problems that have made the news are about rights holders saying "this violates our contract" of some sort.

I'm sure it will be solved, and the internet will just become another transport medium, like RF over Coax or RF-OTA or IPTV/Uverse/FiOS or maybe soon just some standard RJ45/IEEE handoff with mac registration just like you have to register a digital STB with the head-end.

I suspect in the next 15 years the concept of broadcast TV handoff to the consumer will change again. Hope everyone is ready for your television firmware and malware.

- Jared

36

Subject: RE: How do you put a TV station on the Mbone?
Date: Fri, 29 Apr 2011 15:15:42 -0700
From: George Bonser <gbonser@seven.com>

>
> > Imagine: multicast internet radio! Awesome!
>
> That would, indeed, be awesome; when everyone in my office was
> listening to the royal wedding, there would be a *much* higher chance
> of them all being in sync.
>
> Cheers,
> -- jra

Exactly. If more people/networks took advantage of multicast, it would
greatly reduce the bandwidth requirements, particularly for live events.
If there were 50 people listening to a popular radio show or watching a
live TV event in your office, for example, there would be only one feed
crossing the wire into your office. And only one feed crossing into your
provider's network.

I have *no* idea why applications developers have not been more
interested in this, particularly with radio and television stations
providing live streams on the net. It is absolutely a waste of resources
to have a separate stream for each listener of a live event.

There's a layer 9 (or is it 10? <wry grin> -- required for legal reasons)
answer for that. Radio/television stations are required to pay 'performance'
royalties to the 'authors' and 'performers' of the works they transmit over
the internet. Those royalties are based on the _actual_number_ of persons
tuning in to each such work. No 'averaging', no 'estimating', nothing
based on 'ratings', or other 'sampling techniques -- you have to count
the _actual_number_ of people tuned in. It gets messy, but you have to
have 'auditable' records of when each person 'tuned in', and when they
'tuned out'. One _has_ to be able to detect the latter condition under
all possible circumstances. This means you must use a 'loss of signal'
methodology. You can't trust the tuned-in listener to _actually_ stop
listening "just because" they said they would. The people getting the
royalties will claim the tuned-in party lied, and they're due royalties
even after they said they're tuning out. The people _paying_ the fees
won't accept having to pay for people who 'tuned out' in 'non-standard'
ways. Ways like a program (or O/S, for that matter) crash, 'backhoe
fade, etc.

One party worries about people -not- tuning out when they said they are.
The other worries about people tuning out -without- saying they are.

The only to keep both sides happy is to use a methodology that is not
subject to either 'failure' mode. This means a unique 'virtual circuit'
(aka data stream) to each user.

37

Aye. I'm always flabbergasted people complaining how other people should see
the light and start to support multicast so we could reduce global bandwidth
consumption. But multicast does not scale to global use, biggest problem is
that for a router multicast is like flow switching, every flow you need to
program in hardware. This means we'd need to regulate how and who can establish
global multicast flow, which would unavoidably be unfair to some people.

Second problem is security, random Internet user cannot change state in your
routers today (except edge router ARP, which already is exploitable security
problem), with multicast they can cause state to be changed in whole Internet.
You need to be able to limit how many groups port can join, how fast port can
join/leave per second, what groups port can join, same requirement is true for
MSDP peers. It gets quite complex, quite fast, and these filters should be
hardware based. We still regularly have security issues in BGP, it would be
extremely unlikely if multicast didn't have lot of crash-Internet potential,
due to end users ability to add/remove states from the core.

Multicast has been and continues today to be solution for
enterprise/application specific problems in closed domain and of course
academic interest. If we actually want to reduce global bandwidth consumption,
we need protocol which is stateless at least in in core.

38

Or your set top box... multicast joins from STB to DSLAM aren't so hard.
AT&T U-Verse has been doing it for more than five years now.

jy

39

And then if there's music, the SoundExchange rules......to be 'legal' you have to count 'performances' and file forms with information on performances, and pull out the information on the work performed.....preferably with ISRC information.

40

They're not; that's the problem. For the US, at least, the Copyright Office of the Library of Congress has statutory authority in this; for digital performances there is one and only one avenue, and that's through SoundExchange.