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

Mailman List Mirror (Read Only)
1

See, now, I expected to hear that objection.

Internet engineers are prone to try to solve this problem in favor of
the viewer, and their networks -- with their networks winning in case
of a push.

*Program providers*, OTOH, have a completely different set of "optimal"
parameters -- many of which are directly at odds with that approach, and
most of which are completely ignored by Internet engineering types when
working on this stuff.

And OTGH, even if, say, a local TV station wanted to let people do this
sort of thing, *the people they get their programs from* -- both at the
Network and the "provider to Network" level -- will expect to have their
own say in the matter.

*Certainly* there should be a Multicast Cloud, and an easy way for
program providers to dump things into it. But, as you say, who's going
to pay for it is an issue, and how one enforces that is another even
more contentious one.

Layer 9 is a *bitch*, isn't it?

So: if I *wanted* to put my video in the multicast cloud... how would
I do it? I do, after all, now work for a TV network which sells things;
this is not an idle question for me: the more people who can see me,
the better.

Is it a nice, packaged howto, with easily built code?

Pointers?

Cause it seems to me that the fewer speedbumps there are along the way,
the sooner it will happen, all that nassty, nassty commerce, notwithstanding.

Cheers,
-- jra

2

Isn't the real problem with global multicast: "How do we ultimately
bill the broadcaster for all that traffic amplification that happened
*inside* every other AS?" It seems like you'd have to do per-packet
accounting at every router, and coordinate billing/reporting amongst
all providers that saw those packets.

Broadcast encrypted streams. Unicast the key distribution, allowing
interested parties to count, bill, block, allow, litigate, agree...

Rubens

3

And that's the snap answer, yes. But the *load*, while admittedly
lessened over unicast, falls *mostly* to the carriers, who cannot anymore
bill for it, either to end users, providers, *or* as transit.

Will they not complain about having their equipment utilization go up
with no recompense -- for something that is only of benefit to commercial
customers of some other entity?

You're effectively pushing the CDN into the backbone, here; no?

Cheers,
-- jra

4

Like their load didn't go up with no recompense this morning.

What's the break-even point, the number of streams being sent at once where
multicasting it starts taking less resources than N unicast streams?

5

From: "Rubens Kuhl" <rubensk@gmail.com>

>> Isn't the real problem with global multicast: "How do we ultimately
>> bill the broadcaster for all that traffic amplification that
>> happened
>> *inside* every other AS?" It seems like you'd have to do per-packet
>> accounting at every router, and coordinate billing/reporting
>> amongst
>> all providers that saw those packets.

Broadcast encrypted streams. Unicast the key distribution, allowing
interested parties to count, bill, block, allow, litigate, agree...

And that's the snap answer, yes. But the *load*, while admittedly
lessened over unicast, falls *mostly* to the carriers, who cannot anymore
bill for it, either to end users, providers, *or* as transit.

Why not ? One can set conditions for doing multicast replication prior
to doing it, and they might include payment for services. We don`t
have a global Multicast RP for everyone to use, each operator chooses
if, how and when multicast streams are going into their RPs.

Will they not complain about having their equipment utilization go up
with no recompense -- for something that is only of benefit to commercial
customers of some other entity?

Unicast streaming has done it already, as Vladis pointed out...

Rubens

6

Will they not complain about having their equipment utilization go up
with no recompense -- for something that is only of benefit to commercial
customers of some other entity?

Like their load didn't go up with no recompense this morning.

For what it's worth, we didn't see much of bump this morning on our
broadband network... maybe a 10-15% spike (and non-peak hours at that).

What's the break-even point, the number of streams being sent at once where
multicasting it starts taking less resources than N unicast streams?

Video distribution is bound to continue to go in the direction of
Netflix/Youtube where ISPs are going to be highly motivated to find cheaper
ways to provide internet content to their end users. And directly peered,
multicast agreements between CDNs and ISPs are going to be a real quick way
to chop operational costs. Even if that doesn't apply to Netflix content
today, it's bound to matter for content that consumers are going to want to
consume in real time (sporting events).

From the perspective of an ISP operating in a small market, we are seeing a
big shift in usage toward Netflix and netflix-like services that is
necessarily going to change the model of how we provide internet services.
We have limited access to CDN or Content-Producer peering agreements (that
would help to save costs) and, even if we did, we're in no position to
demand ingress cash flow in those agreements (not enough eyeballs!). Since
our users are the ones with the business arrangements with Netflix, and since
their demand is shifting in that direction, I'd imagine we'd jump at a
chance for private multicast agreements, even if demand didn't quite
warrant it at this point.

7

Sorry, but are your eyeballs not already paying you for that bandwidth that
they are consuming. Multicast merely optimises that across your network.

You have 200,000 eyeballs all watching the royal wedding on youtube, at 2Mbps
per stream.

or

You have 200,000 eyeballs all watching the royal wedding on multicast, with
no more than one copy of 2Mbps going over each of your backbone links.

I know which one I'd prefer.

The only place it causes some confusion over charging is if you're the content
ISP which is originating the multicast. How do you charge your TV Channel
customer? Sure, it won't be 2Mbps at your normal per Mbps rate, but equally it
won't be 2Mbps * the number of end users watching the stream. It'll be
somewhere in the middle, probably tending far more towards the 2Mbps end.

Simon

8

From: "Simon Lockhart" <simon@slimey.org>

> Will they not complain about having their equipment utilization go up
> with no recompense -- for something that is only of benefit to
> commercial customers of some other entity?

Sorry, but are your eyeballs not already paying you for that bandwidth
that they are consuming. Multicast merely optimises that across your
network.

You have 200,000 eyeballs all watching the royal wedding on youtube,
at 2Mbps per stream.

or

You have 200,000 eyeballs all watching the royal wedding on multicast,
with no more than one copy of 2Mbps going over each of your backbone links.

I know which one I'd prefer.

He's the devil, I'm just his advocate.

Good. :slight_smile:

The only place it causes some confusion over charging is if you're the content
ISP which is originating the multicast. How do you charge your TV Channel
customer? Sure, it won't be 2Mbps at your normal per Mbps rate, but equally it
won't be 2Mbps * the number of end users watching the stream. It'll be
somewhere in the middle, probably tending far more towards the 2Mbps end.

Sure; people who supply lots of bandwidth to content providers *now* will
probably be unhappy about this idea, but... no business is guaranteed
its business model; that observation goes back at *least* to Robert Heinlein's
first short story, "Lifeline" from 1954(?)... and I *think* he was quoting
Supreme Court Justice Learned Hand, but haven't been able to source it.

The real problem I see myself is that *the Mbone has to be pervasive* (or
mostly so) for this to be a worthwhile investment for providers.

Not to mention it being practical for eyeballs to *get* to it; haven't seen
that HOWTO pointer yet from anyone. :slight_smile:

9

It turns out that as a content provider you can unicast video delivery
without coordinating the admission of your content onto every edge
eyeball network on the planet. It's cheap enough that it makes money on
fairly straght-forward internet business models and it apparently scales
to meet the needs of justin beiber fans.

10

What is missing is an adaptive client (be it flash, or HTML5) which will
transparently use multicast if it's available, and otherwise fall back to
unicast.

I've discussed this many times with IPTV technology providers. Many have agreed
that it's a superb solution, but none have delivered.

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).

Simon

11

Is it all just stalling tactics until IPv6 is everywhere, or am I incorrect that multicast is baked into it rather than tacked on. Unlike the current state of multicast islands were looking at global reach to all IPv6 end points. Even if providers try and stem the flow with AUP's banning sourcing of multicast how many major apps poping up with "you have a valid IPv6 address but multicast is not functioning please contact your ISP as your internet is broken, running at reduced capacity/quality" flooding help desks until ISP's cave in? The only loosers are the ones that were getting paid for transit by the sender, the eyeball networks could well see this as a reduction of backbone utilization

Silas

12

From: Jay Ashworth
Sent: Friday, April 29, 2011 10:13 AM
To: NANOG
Subject: How do you put a TV station on the Mbone? (was: Royal
Wedding...)

> From: "Ryan Malayter"

> > > (cough)multicast(cough)
> >
> > But... but... how do we count the viewers, then?
>
> Isn't the real problem with global multicast: "How do we ultimately
> bill the broadcaster for all that traffic amplification that happened
> *inside* every other AS?" It seems like you'd have to do per-packet
> accounting at every router, and coordinate billing/reporting amongst
> all providers that saw those packets.

See, now, I expected to hear that objection.

Internet engineers are prone to try to solve this problem in favor of
the viewer, and their networks -- with their networks winning in case
of a push.

Should be easy enough on your subscriber ports to use igmp to see who has subscribed to which groups, shouldn't it? Just log igmp changes and there's your accounting.

13

You've conflated my two points. That would tell the *carriers* who's watching
what, but they probably don't care. I was talking about *the providers*
knowing (think DRM and "3096 viewers online").

Cheers,
-- jra

14

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"

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.

R's,
John

15

From nanog-bounces+bonomi=mail.r-bonomi.com@nanog.org Fri Apr 29 12:24:21 2011

16

Imagine: multicast internet radio! Awesome!

I have a feeling streaming is going to stay unicast.

Multicast is a great technical solution in search of a good business problem.

17

You've conflated my two points. That would tell the *carriers* who's
watching
what, but they probably don't care. I was talking about *the
providers*
knowing (think DRM and "3096 viewers online").

Cheers,
-- jra

It would be done the same way it is done currently with cable TV. Who tells CBS how many people are watching? The cable provider knows (or has the capability of knowing with modern digital cable) exactly what channel each cable box is watching at any time.

How does a provider of broadcast television know who is watching? They don't, unless the subscriber has a ratings service device at their prem.

But if "broadcast" events over the internet are treated the same as "broadcast" events over RF, who cares?

18

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"

That is what igmp is for. Only send what I specifically request.

19

Imagine: multicast internet radio! Awesome!

I have a feeling streaming is going to stay unicast.

Multicast is a great technical solution in search of a good business
problem.

--
Tim:>

Multicast is perfect for a live event. Unicast is best for "on demand"
viewing of something.

An event such as today's wedding, a conference viewed in real-time, a
sports event, etc. is well-suited for multicast.

20

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