How do you put a TV station on the Mbone? (was: Royal Wedding...)
----- Original Message -----
From: "Ryan Malayter" <malayter@gmail.com>
On Apr 28, 11:14 pm, Jay Ashworth <j...@baylink.com> wrote:
(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. *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
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
----- Original Message -----
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. 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
On Fri, 29 Apr 2011 13:48:51 EDT, Jay Ashworth said:
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. 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?
On 29/04/11 14:04 -0400, Valdis.Kletnieks@vt.edu wrote:
On Fri, 29 Apr 2011 13:48:51 EDT, Jay Ashworth said:
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. -- Dan White
On 4/29/2011 2:47 PM, Dan White wrote:
On 29/04/11 14:04 -0400, Valdis.Kletnieks@vt.edu wrote:
On Fri, 29 Apr 2011 13:48:51 EDT, Jay Ashworth said: 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.
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
On Fri, Apr 29, 2011 at 2:48 PM, Jay Ashworth <jra@baylink.com> wrote:
----- Original Message -----
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
On Fri Apr 29, 2011 at 01:48:51PM -0400, Jay Ashworth wrote:
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. 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
----- Original Message -----
From: "Simon Lockhart" <simon@slimey.org>
On Fri Apr 29, 2011 at 01:48:51PM -0400, Jay Ashworth wrote:
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. :-)
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. :-)
On Fri Apr 29, 2011 at 03:03:47PM -0400, Jay Ashworth wrote:
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.
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
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
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.
On Apr 29, 2011, at 3:44 PM, John Levine wrote:
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
On 30/04/2011, at 5:44 AM, "John Levine" <johnl@iecc.com> wrote:
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
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
On Fri, 29 Apr 2011 10:48:51 -0700, Jay Ashworth <jra@baylink.com> wrote:
----- Original Message -----
From: "Rubens Kuhl" <rubensk@gmail.com>
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?
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.
----- Original Message -----
From: "Octavio Alvarez" <alvarezp@alvarezp.ods.org>
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.
Yup: that's what the Content Industry does: invents problems just for the sake of it. Cheers, -- jra
Once upon a time, Octavio Alvarez <alvarezp@alvarezp.ods.org> said:
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.
How does this affect peering, when some providers want bandwidth ratios in a certain range? I can also see how this affects the ISPs providing bandwidth to the content providers. In our colo for example, we rate-limit customers to the paid-for bandwidth at the colo port. With multicast however, they could use significantly more bandwidth, because every router in our network could potentially send the stream to many ports. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
On Sat, 30 Apr 2011, Chris Adams wrote:
I can also see how this affects the ISPs providing bandwidth to the content providers. In our colo for example, we rate-limit customers to the paid-for bandwidth at the colo port. With multicast however, they could use significantly more bandwidth, because every router in our network could potentially send the stream to many ports.
Only if you're using hubs or dumb switches. If your switch is multicast aware, the multicast traffic only goes to ports with active listeners for a particular group. Routers send multicast traffic only if there are active downstream listeners (where "downstream" doesn't mean the same for unicast as it does multicast). -- Antonio Querubin e-mail: tony@lavanauts.org xmpp: antonioquerubin@gmail.com
On Sat, 30 Apr 2011 10:34:15 -0700, Chris Adams <cmadams@hiwaay.net> wrote:
Once upon a time, Octavio Alvarez <alvarezp@alvarezp.ods.org> said:
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.
How does this affect peering, when some providers want bandwidth ratios in a certain range?
I can also see how this affects the ISPs providing bandwidth to the content providers. In our colo for example, we rate-limit customers to the paid-for bandwidth at the colo port. With multicast however, they could use significantly more bandwidth, because every router in our network could potentially send the stream to many ports.
You are billing your content provider for the bandwidth consumption at his port not because you intend to bill him for the bandwidth of content provided, but for the bandwidth of content delivered to the end user! The end-user is ALREADY PAYING for that bandwidth! Something is *really* broken there. -- Octavio. Twitter: @alvarezp2000 -- Identi.ca: @alvarezp
From nanog-bounces+bonomi=mail.r-bonomi.com@nanog.org Fri Apr 29 12:24:21 2011 Date: Fri, 29 Apr 2011 14:23:23 -0300 Subject: Re: How do you put a TV station on the Mbone? (was: Royal Wedding...) From: Rubens Kuhl <rubensk@gmail.com> To: Nanog <nanog@nanog.org>
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
On 4/29/11 10:12 AM, Jay Ashworth wrote:
----- Original Message -----
From: "Ryan Malayter" <malayter@gmail.com>
On Apr 28, 11:14 pm, Jay Ashworth <j...@baylink.com> wrote:
(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.
*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.
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.
On Fri, Apr 29, 2011 at 3:11 PM, Joel Jaeggli <joelja@bogus.com> wrote:
On 4/29/11 10:12 AM, Jay Ashworth wrote:
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.
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:>
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.
----- Original Message -----
From: "George Bonser" <gbonser@seven.com>
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.
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? :-) Cheers, -- jra
On Fri Apr 29, 2011 at 05:40:59PM -0400, Jay Ashworth wrote:
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? :-)
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
----- Original Message -----
From: "Simon Lockhart" <simon@slimey.org>
I have in my hand an NTSC video cable and an XLR with audio. How do I hook that to the mbone? :-)
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.
Really. It's that trivial? Ok. Cool. Anyone know if Road Runner's one of those? And how do viewers watch it? Cheers, -- jra
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? :-)
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.
---- Original Message -----
From: "Tim Durack" <tdurack@gmail.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
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.
On Fri, 29 Apr 2011, George Bonser wrote:
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
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) -- david raistrick http://www.netmeister.org/news/learn2quote.html drais@icantclick.org http://www.expita.com/nomime.html
---- Original Message -----
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. :-)
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? :-) Thanks for the input, David. Cheers, -- jra
On Fri, 29 Apr 2011, Jay Ashworth wrote:
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? :-)
Because it's not an experience I care to repeat. ;-) Today, I make video games. MUCH more fun! (who knew, content CAN be fun) -- david raistrick http://www.netmeister.org/news/learn2quote.html drais@icantclick.org http://www.expita.com/nomime.html
On (2011-04-29 18:34 -0400), david raistrick wrote:
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.
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. -- ++ytti
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.
On 4/29/2011 8:57 PM, Robert Bonomi wrote:
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.
Really? How do they detect the number of people that were gathered around my screen while I was watching? Does that mean I'll be able to get a refund (pro-rated of course) for falling asleep during UFC 129 this weekend? -- Dave
Date: Mon, 02 May 2011 10:11:34 -0400 From: David Sparro <dsparro@gmail.com> Subject: Re: How do you put a TV station on the Mbone?
On 4/29/2011 8:57 PM, Robert Bonomi wrote:
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.
Really?
Yeah, _really_. That is what the law says.
How do they detect the number of people that were gathered around my screen while I was watching? Does that mean I'll be able to get a refund (pro-rated of course) for falling asleep during UFC 129 this weekend?
There is an 'assumption' built into the applicable implementation rules issued by the government that 'one active display device' == 'one viewer'. How close that assumption is to 'objective reality' is irrelevant to the legalities involved in calculating royalties due.
On Fri, Apr 29, 2011 at 05:51:25PM -0400, Jay Ashworth wrote:
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. :) IP multicast was the only way for us to see what happened, live. Unicast failed miserably. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Daniel, On Fri, Apr 29, 2011 at 7:44 PM, Daniel Roesen <dr@cluenet.de> wrote:
On Fri, Apr 29, 2011 at 05:51:25PM -0400, Jay Ashworth wrote:
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. :)
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
On Apr 29, 2011, at 7:44 PM, Daniel Roesen wrote:
IP multicast was the only way for us to see what happened, live. Unicast failed miserably.
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
Once upon a time, Daniel Roesen <dr@cluenet.de> said:
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.
We had a TV in the office then, but now we don't. The other big news event of the week, the tornadoes in the south (especially here in Alabama), meant we were filling up our office bandwidth much of the day Wednesday, watching the local weathermen to find out if we (or our family and friends) were next. This was an exceedingly unusual event in terms of magnitude, but the watching to see where the tornadoes go part is fairly regular around here this time of year. Every time there is a severe weather outbreak, we see our bandwidth usage go up significantly (especially when it is during the business day). As an admin at a small ISP, I'll admit we don't have multicast set up in our network, in part because every time I've looked, I just end up confused. Kind of like IPv6 was for a long time, except IPv6 has more attention and so more people writing better (easier to understand) info. Of course, we provide DSL via PPPoE (wholesaler, so we don't have a choice in the setup), so there isn't much we can do to help with that level. That's where we could gain the most of course; we sometimes see nearly double the DSL traffic for big events (not for the wedding though, since most of our customers don't have electricity). The "last mile" is usually the bottleneck, but that's the hardest nut to crack. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
On Apr 29, 2011, at 4:40 PM, Tim Durack wrote:
On Fri, Apr 29, 2011 at 3:11 PM, Joel Jaeggli <joelja@bogus.com> wrote:
On 4/29/11 10:12 AM, Jay Ashworth wrote:
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.
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.
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")
On Apr 29, 2011, at 8:46 PM, Jared Mauch wrote:
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.
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 occasional large live "event" - and when I say occasional, I mean not a few per year - likely could be helped if there were a magic wand to wave which made multicast work for no CapEx or OpEx and perfectly billed. But the vast majority of traffic cannot be served by multi-cast. The real cost of multi-cast (when it works at all!) may be too great for the small benefit, even ignoring the billing mechanism. People's proclivities change. As a vendor / supplier / company who gets paid, we have to adjust to the wishes of the people paying us as best we can. Or someone else will. -- TTFN, patrick
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 cost? That I think is the real issue. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
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 occasional large live "event" - and when I say occasional, I mean not a few per year - likely could be helped if there were a magic wand to wave which made multicast work for no CapEx or OpEx and perfectly billed. But the vast majority of traffic cannot be served by multi- cast.
The real cost of multi-cast (when it works at all!) may be too great for the small benefit, even ignoring the billing mechanism.
People's proclivities change. As a vendor / supplier / company who gets paid, we have to adjust to the wishes of the people paying us as best we can. Or someone else will.
-- TTFN, patrick
Hi, Patrick. It takes some coordination but imagine someone like Comcast or Roadrunner or AT&T says "hey, want to watch the March Madness games or the Masters or the Olympics or the World Series? Here, download this application and watch it with much better performance than streaming on a web browser." They would rather easily know how many customer ports are watching the broadcast. As I mentioned earlier, Verizon Wireless already uses it in their mobile network. It would take some coordination between the content providers and the large consumer networks but the benefits would be pretty substantial for the customers. So the provider could go to the cable news network and make an offer to provide live content via multicast to their subscribers that would not eat a huge amount of resources for either the content provider or the network provider. It doesn't make sense for a lot of on-demand access but makes a lot of sense for live content like radio talk shows, news, sports, etc. Even webcams could be upgraded to provide streaming content rather than individual frames without chewing up a lot of resources. It wouldn't matter if 1 or 1 million people are watching, the bandwidth resource requirement would remain the same. If there are 10,000 Comcast subscribers watching exactly the same live event on the net, sending 10,000 streams of exactly the same data is dumb and it doesn't have to be that way.
----- Original Message -----
From: "George Bonser" <gbonser@seven.com>
It doesn't make sense for a lot of on-demand access but makes a lot of sense for live content like radio talk shows, news, sports, etc. Even webcams could be upgraded to provide streaming content rather than individual frames without chewing up a lot of resources. It wouldn't matter if 1 or 1 million people are watching, the bandwidth resource requirement would remain the same.
If there are 10,000 Comcast subscribers watching exactly the same live event on the net, sending 10,000 streams of exactly the same data is dumb and it doesn't have to be that way.
And, more to the point, as we proceed more and more into a live-tweet, social TV world, *having all your viewers within a second or two of each other* becomes more and more important. My experience is that that's *much* easier to manage in a multicast environment, than with live-unicast streaming -- especially when there are multiple server clusters in different places for load balancing. Cheers, -- jra
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/05/2011, at 1:33 PM, George Bonser wrote:
f there are 10,000 Comcast subscribers watching exactly the same live event on the net, sending 10,000 streams of exactly the same data is dumb and it doesn't have to be that way.
IMHO, It's pretty likely that those 10,000 streams will originate in as few as 5 but as many as 40 or so individual CDN-type devices imbedded deep in Comcast local networks. Therefore, the consumption of bandwidth that seems wasteful is limited and in proportion to the distance between the viewers and these devices. The same devices can be used to originate long-tail (not often watched) content, Video on Demand content, time- shifted content and so forth. Multicast is an elegant solution to a dwindling problem set. Patrick rightly points out that enabling multicast to the end user may just not be worth the operational cost. Multicast as a tool the provider uses on the other hand is well worth the expense. You might use it to broadcast content to your CDN-like devices or keep your trading desks up to date with the latest ticker feeds. AT&T uses multicast to push video channels (the IP equivalent of broadcast TV) down to and through DSLAMs for UVerse. But viewing habits dictate technology used. For instance, AT&T might use multicast to 'broadcast' television channels but for an "instant channel change" feature hoards of unicast servers stand ready to feed UVerse users who haven't figured out how to use a program guide to navigate their sets and can't bear the latency of a S,G join. :-) jy -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) iF4EAREIAAYFAk2/s4AACgkQxvthcni5E2/naQD+PHifzWPC2mhknrzhIIjqstT+ HoBJ2/Lk4ZpktX+00osA/0OEDL5SQHeg++c9wo40hJuxMRn66ViPOXNq8T7ckWdZ =yeYh -----END PGP SIGNATURE-----
Multicast is an elegant solution to a dwindling problem set.
And that is fundamentally where we disagree. I see this as not "elegant" at all. It is a fundamental part of the protocol suite. It is no more "elegant" than unicast. I also believe that it will be the wireless operators that bring this back to widespread use as wireless devices are used for more than simply placing phone calls. Time will tell, but it looks like the total use of multicast for content delivery is currently increasing. It just isn't increasing in the realm of home internet providers, yet, but I believe it will as people use home internet for things that they had traditionally used other services for such as broadcast radio and tv.
On 04/05/2011, at 1:54 AM, George Bonser <gbonser@seven.com> wrote:
Multicast is an elegant solution to a dwindling problem set.
And that is fundamentally where we disagree. I see this as not "elegant" at all. It is a fundamental part of the protocol suite. It is no more "elegant" than unicast. I also believe that it will be the wireless operators that bring this back to widespread use as wireless devices are used for more than simply placing phone calls. Time will tell, but it looks like the total use of multicast for content delivery is currently increasing. It just isn't increasing in the realm of home internet providers, yet, but I believe it will as people use home internet for things that they had traditionally used other services for such as broadcast radio and tv.
I dunno, I think it's elegant, in think Deering did an incredible job to create it and some many years ago I played a role to bring multicast to the Internet at large. I believed that multicast would play a huge role in the delivery of content, then. Trouble was that the way that people want to consume video means most of it is time-shifted. Folks in charge of networks didn't understand the technology and marketing people thought turning on multicast meant giving something away. I finally settled on the notion that multicast is a tool for service providers/enterprises to use but that it wouldn't ever be as pervasive as I'd hoped. As for wireless operators? The wireless medium itself is a broadcast network, why bother with multicast? jy
----- Original Message -----
From: "Jeffrey S. Young" <young@jsyoung.net>
I think it's elegant, in think Deering did an incredible job to create it and some many years ago I played a role to bring multicast to the Internet at large. I believed that multicast would play a huge role in the delivery of content, then.
Trouble was that the way that people want to consume video means most of it is time-shifted. Folks in charge of networks didn't understand the technology and marketing people thought turning on multicast meant giving something away. I finally settled on the notion that multicast is a tool for service providers/enterprises to use but that it wouldn't ever be as pervasive as I'd hoped.
I think that George's POV -- which is also mine -- is that as the world shifts, the percentage of video distribution which is amenable to multicast, and not well served by unicast, is likely to grow, and it would be a Good Idea to be ready for that situation already when it arrives. Cheers, -- jra
I think that George's POV -- which is also mine -- is that as the world shifts, the percentage of video distribution which is amenable to multicast, and not well served by unicast, is likely to grow, and it would be a Good Idea to be ready for that situation already when it arrives.
Really? If anything, I'd say quite the opposite. Watching media in the time-slot that someone else has decided on is *so* 20th-century - I can't remember the last time I sat down to actively watch a programme in its original transmission slot. (As opposed to having the TV on as background, e.g. 15 minutes of breakfast news in the morning). I guess multicast to a recording application (or appliance) might work - but essentially my requirement is strongly skewed towards video-on-demand. I have absolutely zero interest in sport of any kind though - I'm given to understand there's quite a high demand for live viewing of that. Regards, Tim.
I think that George's POV -- which is also mine -- is that as the world shifts, the percentage of video distribution which is amenable to multicast, and not well served by unicast, is likely to grow, and it would be a Good Idea to be ready for that situation already when it arrives.
Really? If anything, I'd say quite the opposite. Watching media in the time-slot that someone else has decided on is *so* 20th-century - I can't remember the last time I sat down to actively watch a programme in its original transmission slot. (As opposed to having the TV on as background, e.g. 15 minutes of breakfast news in the morning). I guess multicast to a recording application (or appliance) might work - but essentially my requirement is strongly skewed towards video-on-demand.
Agreed, it seems the only demand really for this live viewing is sport, news and background programming like the mentioned breakfast television. But there is still the demand to just have something on in the background, whatever that may be.
I have absolutely zero interest in sport of any kind though - I'm given to understand there's quite a high demand for live viewing of that.
Apparently so.. -- Leigh Porter ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
On Wed, May 4, 2011 at 12:45 PM, Leigh Porter <leigh.porter@ukbroadband.com> wrote:
Agreed, it seems the only demand really for this live viewing is sport, news and background programming like the mentioned breakfast television.
I disagree with the general notion that multicast is not useful except for live content. Allow me to give a couple of examples that would probably be implemented if we really had a multicast-enabled Internet, end-to-end: WINDOWS UPDATES Most of us have some number of Windows machines on our networks, probably a large number. These updates are pervasive, and yet they are largely delivered to end-users as unicast downloads. If we all had mcast, the latest and greatest Windows Update would probably be available via mcast, and your PC would join the appropriate group, receive the update, and be able to install it, without any unicast traffic at all. There may be several groups for users who have different access network speeds, and your machine may need to fall-back to unicast to retrieve last week's updates or get packets/chunks that it missed, but this is far from difficult to implement. ON-DEMAND MOVIES While on-demand movies are unicast today, there's no reason a content provider couldn't take advantage of multicast for the most popular movies, let's say "new releases." We know that the latest movies are more popular than older titles, because they consume much more shelf space at Blockbuster, and more storage slots in the corner RedBox. I might receive the first few minutes of my on-demand movie by unicast, and "catch up" to a high-speed multicast stream which repeatedly "plays" the same movie, faster than the real-time data rate, for users with sufficient access speed to download it. My set-top-box would transition from unicast to cached data it received via mcast, resulting in a large bandwidth savings for popular titles. As you can see, multicast can be useful for distribution of popular time-shifted content and data, not just sports, news, and traditional live programming. Whether or not we ever see wide adoption of multicast support on end-user access networks, well, that seems increasingly unlikely given the consolidation of ISP/last-mile and content producers/owners. The less ISP networks look like "common carriers" from a business perspective, the less motive they have to act like a common carrier, and provide efficient, cost-effective access to anything users wish to download. For someone like Comcast, multicast is the ultimate "boogie man." End-users being able to originate content at low cost to anyone and everyone, without expensive CDNs or network connectivity? I could start my own movie channel, license some indie films I want to stream, throw some ads over them, and be in competition with traditional television networks who pay for satellite transponders, negotiate for carriage, etc. There is no way a Comcast/NBC Universal would ever make the mistake of giving their users unfettered access to multicast. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
On 5/4/2011 2:07 PM, Jeff Wheeler wrote:
Agreed, it seems the only demand really for this live viewing is sport, news and background programming like the mentioned breakfast television. I disagree with the general notion that multicast is not useful except for live content. Allow me to give a couple of examples that would
On Wed, May 4, 2011 at 12:45 PM, Leigh Porter <leigh.porter@ukbroadband.com> wrote: probably be implemented if we really had a multicast-enabled Internet, end-to-end:
WINDOWS UPDATES Most of us have some number of Windows machines on our networks, probably a large number. These updates are pervasive, and yet they are largely delivered to end-users as unicast downloads. If we all had mcast, the latest and greatest Windows Update would probably be available via mcast, and your PC would join the appropriate group, receive the update, and be able to install it, without any unicast traffic at all. There may be several groups for users who have different access network speeds, and your machine may need to fall-back to unicast to retrieve last week's updates or get packets/chunks that it missed, but this is far from difficult to implement.
Local caching is MUCH more efficient than having the same traffic running in streams and depending on everyone's PC to try and update in the same time frame.
ON-DEMAND MOVIES While on-demand movies are unicast today, there's no reason a content provider couldn't take advantage of multicast for the most popular movies, let's say "new releases." We know that the latest movies are more popular than older titles, because they consume much more shelf space at Blockbuster, and more storage slots in the corner RedBox. I might receive the first few minutes of my on-demand movie by unicast, and "catch up" to a high-speed multicast stream which repeatedly "plays" the same movie, faster than the real-time data rate, for users with sufficient access speed to download it. My set-top-box would transition from unicast to cached data it received via mcast, resulting in a large bandwidth savings for popular titles.
Same issue as above, even if I am watching the latest popular movie moving between a multicast and unicast stream everytime I pause it to get another beer isn't realistic. The chances that there will be a multicast stream that will be in synch with me is not high at all.
As you can see, multicast can be useful for distribution of popular time-shifted content and data, not just sports, news, and traditional live programming.
I don't think your examples demonstrate that nor do I think the service providers, even the folks that understand what is meant by the term, fear multicast at all. They do feel threatened by the increase in unicast OTT video but multicast in large amounts without the layer 1/2 service provider being engaged is a long way off. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------
On Wed, May 4, 2011 at 2:22 PM, Scott Helms <khelms@ispalliance.net> wrote:
Local caching is MUCH more efficient than having the same traffic running in streams and depending on everyone's PC to try and update in the same time
This only works, of course, if there is a local cache which PCs are aware of.
Same issue as above, even if I am watching the latest popular movie moving between a multicast and unicast stream everytime I pause it to get another beer isn't realistic. The chances that there will be a multicast stream that will be in synch with me is not high at all.
You must have skipped over the word "cache" when reading my post. I'll explain again in a little more detail, so you can understand why the consumer who pauses the film to go get a snack is actually an advantage for this system. Let's say your typical movie is 5Mb/s and you want to start watching it right away; you aren't willing to wait several minutes (or longer) until the next "multicast loop" begins. You press play and begin receiving a 5Mb/s unicast stream, but your STB also joins an mcast group for that movie, because it is very popular and being watched by a huge number of users during peak time. The mcast stream is 20Mb/s, or 400% of real-time. No matter what point the loop is at when you join, you will cache the multicast data and eventually reach a point in the movie where you no longer need the unicast stream. Given a 2 hour movie, the worst-case is that you'll join just a minute after the stream/loop started, in which case it will be about 30 minutes before you start viewing from multi-casted, STB-cached data, instead of unicast streamed data. With two subscribers watching the movie given worst-case circumstances, there is a bandwidth conservation of: (users - 1) * 5Mb/s * 90min, or a mean savings around 37%, for only two users. If ten users are watching, your worst-case bandwidth savings will be greater, 33.7Mb/s, or about 67%. If, on the other hand, you start watching the movie, then realize it would be more enjoyable with some popcorn, your STB is already listening to the mcast stream and caching the movie for you. The longer it takes your popcorn to cook, the greater the chance that the STB will start receiving mcast data for the beginning of the movie before you un-pause it, which means you would not need the unicast stream at all. In fact, if you include the probability that some users will be able to receive data via mcast earlier than 30 minutes into the movie, because they didn't get unlucky and press play at the worst-case moment, your bandwidth savings for a group of ten viewers and a 400% real-time mcast stream will be about 80%. The potential savings is limited by the over-speed of the mcast stream vs real-time, and the density of mcast listener groups. Given that access network speeds continue to increase, yet ISPs are really not increasing "bandwidth caps," it is reasonable to assume that an ISP might like to allow its subscribers to receive a very fast mcast stream for a short period of time, instead of all of those subscribers receiving many, slow mcast streams. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
On May 4, 2011, at 3:37 48PM, Jeff Wheeler wrote:
On Wed, May 4, 2011 at 2:22 PM, Scott Helms <khelms@ispalliance.net> wrote:
Local caching is MUCH more efficient than having the same traffic running in streams and depending on everyone's PC to try and update in the same time
This only works, of course, if there is a local cache which PCs are aware of.
Same issue as above, even if I am watching the latest popular movie moving between a multicast and unicast stream everytime I pause it to get another beer isn't realistic. The chances that there will be a multicast stream that will be in synch with me is not high at all.
You must have skipped over the word "cache" when reading my post. I'll explain again in a little more detail, so you can understand why the consumer who pauses the film to go get a snack is actually an advantage for this system.
Let's say your typical movie is 5Mb/s and you want to start watching it right away; you aren't willing to wait several minutes (or longer) until the next "multicast loop" begins. You press play and begin receiving a 5Mb/s unicast stream, but your STB also joins an mcast group for that movie, because it is very popular and being watched by a huge number of users during peak time. The mcast stream is 20Mb/s, or 400% of real-time. No matter what point the loop is at when you join, you will cache the multicast data and eventually reach a point in the movie where you no longer need the unicast stream.
Given a 2 hour movie, the worst-case is that you'll join just a minute after the stream/loop started, in which case it will be about 30 minutes before you start viewing from multi-casted, STB-cached data, instead of unicast streamed data. With two subscribers watching the movie given worst-case circumstances, there is a bandwidth conservation of: (users - 1) * 5Mb/s * 90min, or a mean savings around 37%, for only two users. If ten users are watching, your worst-case bandwidth savings will be greater, 33.7Mb/s, or about 67%.
If, on the other hand, you start watching the movie, then realize it would be more enjoyable with some popcorn, your STB is already listening to the mcast stream and caching the movie for you. The longer it takes your popcorn to cook, the greater the chance that the STB will start receiving mcast data for the beginning of the movie before you un-pause it, which means you would not need the unicast stream at all.
In fact, if you include the probability that some users will be able to receive data via mcast earlier than 30 minutes into the movie, because they didn't get unlucky and press play at the worst-case moment, your bandwidth savings for a group of ten viewers and a 400% real-time mcast stream will be about 80%.
The potential savings is limited by the over-speed of the mcast stream vs real-time, and the density of mcast listener groups. Given that access network speeds continue to increase, yet ISPs are really not increasing "bandwidth caps," it is reasonable to assume that an ISP might like to allow its subscribers to receive a very fast mcast stream for a short period of time, instead of all of those subscribers receiving many, slow mcast streams.
A crucial point here is the cost ratio between bandwidth and disk space, since ultimately consumers pay for both. My own STB can cache the movie -- but that requires local disk. On the other hand, as you point out, it saves on bandwidth. (Note that I'm interpreting "cost" broadly to include not just the capital cost of, say, the disk, but all of the associated operational costs, including what ISPs need to spend on provisioning and operating multicast, consumer reactions to local disks being full or dying, etc. Of course, I don't know what the answer is now, let alone over time... --Steve Bellovin, https://www.cs.columbia.edu/~smb
----- Original Message -----
From: "Jeff Wheeler" <jsw@inconcepts.biz>
The potential savings is limited by the over-speed of the mcast stream vs real-time, and the density of mcast listener groups. Given that access network speeds continue to increase, yet ISPs are really not increasing "bandwidth caps," it is reasonable to assume that an ISP might like to allow its subscribers to receive a very fast mcast stream for a short period of time, instead of all of those subscribers receiving many, slow mcast streams.
You know what would make this work *well*? If IAPs *didn't include mcast traffic in your cap*. Since the reason for their caps is, in the final analysis *to limit THEIR transit costs*, multicast would seem to be a really good means toward that end, unless my final analysis is contradicted by something better justified and documented... This would turn multicast into a Consumer-pull technology. Cheers, -- jra
--As of May 4, 2011 5:43:04 PM -0400, Jay Ashworth is alleged to have said:
You know what would make this work *well*? If IAPs *didn't include mcast traffic in your cap*. Since the reason for their caps is, in the final analysis *to limit THEIR transit costs*, multicast would seem to be a really good means toward that end, unless my final analysis is contradicted by something better justified and documented...
This would turn multicast into a Consumer-pull technology.
--As for the rest, it is mine. Assuming that is the actual reason for traffic caps, instead of just the stated reason. In many cases it seems like traffic caps are being rolled out in an effort to stymie the streaming-content services (Hulu, Youtube, etc.) that compete with the ISP's other business of selling TV/Cable service. If that is the case, multicast is just a way for the services the ISPs are trying to interfere with to lower their costs and increase their quality. So not including that traffic in their cap is the last thing they would want to do. Daniel T. Staal --------------------------------------------------------------- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. ---------------------------------------------------------------
----- Original Message -----
From: "Daniel Staal" <DStaal@usa.net>
--As of May 4, 2011 5:43:04 PM -0400, Jay Ashworth is alleged to have said:
You know what would make this work *well*? If IAPs *didn't include mcast traffic in your cap*. Since the reason for their caps is, in the final analysis *to limit THEIR transit costs*, multicast would seem to be a really good means toward that end, unless my final analysis is contradicted by something better justified and documented...
This would turn multicast into a Consumer-pull technology.
Assuming that is the actual reason for traffic caps, instead of just the stated reason. In many cases it seems like traffic caps are being rolled out in an effort to stymie the streaming-content services (Hulu, Youtube, etc.) that compete with the ISP's other business of selling TV/Cable service.
If that is the case, multicast is just a way for the services the ISPs are trying to interfere with to lower their costs and increase their quality. So not including that traffic in their cap is the last thing they would want to do.
Sure. What better way to expose them for that? :-) No business is entitled to protection of its business model. Cheers, -- jra
----- Original Message -----
On Wed, May 4, 2011 at 6:20 PM, Jay Ashworth <jra@baylink.com> wrote:
No business is entitled to protection of its business model.
Unless it has a market monopoly, deep pockets, and lobbyist friends.
That does not mean they're *entitled* to it... just that they can *get* it. Cheers, -- jra
On Wed, May 4, 2011 at 7:19 PM, Tim Durack <tdurack@gmail.com> wrote:
On Wed, May 4, 2011 at 6:20 PM, Jay Ashworth <jra@baylink.com> wrote:
No business is entitled to protection of its business model.
Unless it has a market monopoly, deep pockets, and lobbyist friends.
http://arstechnica.com/tech-policy/news/2011/05/after-approving-comcastnbc-d... I rest my case. -- Tim:>
Tim Durack wrote:
On Wed, May 4, 2011 at 7:19 PM, Tim Durack <tdurack@gmail.com> wrote:
On Wed, May 4, 2011 at 6:20 PM, Jay Ashworth <jra@baylink.com> wrote:
No business is entitled to protection of its business model.
Unless it has a market monopoly, deep pockets, and lobbyist friends.
http://arstechnica.com/tech-policy/news/2011/05/after-approving-comcastnbc-d...
I rest my case.
Check out the movie, 'Casino Jack', about Jack Abramoff. My favorite line is when he's in the slammer and telling another inmate what he does for a living, the inmate says, "Lobbyist... is that illegal?".
I disagree with the general notion that multicast is not useful except for live content.
Oh, there are all SORTS of things it would be well-suited for. Live content is just the lowest hanging fruit.
WINDOWS UPDATES Most of us have some number of Windows machines on our networks, probably a large number. These updates are pervasive, and yet they are largely delivered to end-users as unicast downloads. If we all had mcast, the latest and greatest Windows Update would probably be available via mcast, and your PC would join the appropriate group, receive the update, and be able to install it, without any unicast traffic at all. There may be several groups for users who have different access network speeds, and your machine may need to fall-back to unicast to retrieve last week's updates or get packets/chunks that it missed, but this is far from difficult to implement.
As anyone can send packets to a multicast group, I would be very wary of such a thing. However, notification that an update is available could be multicast which would greatly reduce polling.
I might receive the first few minutes of my on-demand movie by unicast, and "catch up" to a high-speed multicast stream which repeatedly "plays" the same movie, faster than the real-time data rate, for users with sufficient access speed to download it. My set-top-box would transition from unicast to cached data it received via mcast, resulting in a large bandwidth savings for popular titles.
Interesting notion assuming you decided to watch shortly enough into the movie to do this. Another alternative would be to simply have regularly scheduled show times ... but that isn't exactly "on demand" but a "your movie will begin in 5 minutes" while additional users are lined up on a multicast group would still have some potential value. Or maybe even some hybrid of the two approaches. Generally, any content that might be of interest to multiple users at the same time can generally take advantage of multicast, even if it is only a notification of something. Say twitter used a multicast group to broadcast tweets with the most popular hashtags. A large number of clients could pick up those tweets without having to poll for them. Others would catch up using the conventional poll but it would have the potential to greatly reduce the amount of information that would transfer on such polls. There is a security aspect to such things, though, as how do you know the content is from a trusted source? That is the bugaboo with multicast. It needs to be information that isn't going to hurt anything if it is bogus. Also, it opens up a DoS possibility with noise traffic sent to the multicast group.
On Wed, 4 May 2011, George Bonser wrote:
There is a security aspect to such things, though, as how do you know the content is from a trusted source? That is the bugaboo with multicast. It needs to be information that isn't going to hurt anything if it is bogus. Also, it opens up a DoS possibility with noise traffic sent to the multicast group.
SSM with encryption? -- Antonio Querubin e-mail: tony@lavanauts.org xmpp: antonioquerubin@gmail.com
There is a security aspect to such things, though, as how do you know the content is from a trusted source? That is the bugaboo with multicast. It needs to be information that isn't going to hurt anything if it is bogus. Also, it opens up a DoS possibility with noise traffic sent to the multicast group.
SSM with encryption?
Well, certainly, but source address can be very easily spoofed with a UDP multicast stream. Now that could be mitigated with a lot of network configuration rules but something is needed that just works without all that. So using multicast for things like software updates to computers over the general internet to the general public probably isn't going to work. Encryption is also an issue because it doesn't really work well over multicast. How do I encrypt something in a way that anyone can decrypt but nobody can duplicate? If I have a separate stream per user, that is easy. If I have one stream for all users, that is harder. The answer is probably in some sort of digital signature but not really encryption. Using public/private key encryption over multicast, I would have to distribute the private key so others could decrypt the content. If they have the private key, they can generate a public key to use to generate content. Encryption is probably overkill anyway. What is needed is a mechanism simply to say that the content is certified to have come from the source it claims to come from. So ... basically ... better not to use multicast for anything you really might have any security issues with. Fine for broadcasting a video, not so fine for a kernel update.
On Thu, May 5, 2011 at 1:55 AM, George Bonser <gbonser@seven.com> wrote:
multicast. How do I encrypt something in a way that anyone can decrypt but nobody can duplicate? If I have a separate stream per user, that is
Have you ever seen a CableCARD? That's pretty much what it does, except not "anyone" can decrypt it -- you need to subscribe to some TV channels. There has been quite a bit of work in "black-boxing" the decryption of broadcast/multicast streams to make it difficult for end-users to pirate the content. That's why you see HDCP logos in the marketing fluff for displays and graphics cards, etc.
Encryption is probably overkill anyway. What is needed is a mechanism simply to say that the content is certified to have come from the source it claims to come from. So ... basically ... better not to use multicast for anything you really might have any security issues with. Fine for broadcasting a video, not so fine for a kernel update.
This is a solved problem. Not only are you able to verify the computed checksum of a downloaded file against the distributor's published checksum, there are plenty of applications that do this for you -- torrent programs check each chunk and throw away malicious/erroneous ones. There are certainly things that need work before I can start up Jeff's Internet Movie Channel and go into competition with HBO, but for the most part, these are solvable if networks decided to do it. The big limitation is there can't be infinite groups -- FIB is only so big and there is no agreeable mechanism for sharing the number that can be made to exist, given current (and foreseeable) routers. Since so many "eyeballs" are sitting on ISPs that also own television networks and other media properties, though, I don't think we will get multicast anytime soon. -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
----- Original Message -----
From: "Jeff Wheeler" <jsw@inconcepts.biz>
There are certainly things that need work before I can start up Jeff's Internet Movie Channel and go into competition with HBO, but for the most part, these are solvable if networks decided to do it. The big limitation is there can't be infinite groups -- FIB is only so big and there is no agreeable mechanism for sharing the number that can be made to exist, given current (and foreseeable) routers. Since so many "eyeballs" are sitting on ISPs that also own television networks and other media properties, though, I don't think we will get multicast anytime soon.
Unless (what I assert is) Google's plan to engender muni fiber last-mile really catches fire -- at which point it will become logistically practical for people like Chris Adams to compete with people like Road Runner... and you'll have your end-user transport. Bet me cash Google City will be multicast capable. Cheers -- jra
Once upon a time, Jay Ashworth <jra@baylink.com> said:
Unless (what I assert is) Google's plan to engender muni fiber last-mile really catches fire -- at which point it will become logistically practical for people like Chris Adams to compete with people like Road Runner... and you'll have your end-user transport.
Yay, I'm an example on NANOG! :-) I wish Huntsville had been chosen by the GOOG. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
On May 5, 2011, at 1:55 54AM, George Bonser wrote:
There is a security aspect to such things, though, as how do you know the content is from a trusted source? That is the bugaboo with multicast. It needs to be information that isn't going to hurt anything if it is bogus. Also, it opens up a DoS possibility with noise traffic sent to the multicast group.
SSM with encryption?
Well, certainly, but source address can be very easily spoofed with a UDP multicast stream. Now that could be mitigated with a lot of network configuration rules but something is needed that just works without all that.
So using multicast for things like software updates to computers over the general internet to the general public probably isn't going to work. Encryption is also an issue because it doesn't really work well over multicast. How do I encrypt something in a way that anyone can decrypt but nobody can duplicate? If I have a separate stream per user, that is easy. If I have one stream for all users, that is harder. The answer is probably in some sort of digital signature but not really encryption.
Using public/private key encryption over multicast, I would have to distribute the private key so others could decrypt the content. If they have the private key, they can generate a public key to use to generate content.
Encryption is probably overkill anyway. What is needed is a mechanism simply to say that the content is certified to have come from the source it claims to come from. So ... basically ... better not to use multicast for anything you really might have any security issues with. Fine for broadcasting a video, not so fine for a kernel update.
See the work of the IETF MIKEY working group. --Steve Bellovin, https://www.cs.columbia.edu/~smb
----- Original Message -----
From: "Steven Bellovin" <smb@cs.columbia.edu>
Encryption is probably overkill anyway. What is needed is a mechanism simply to say that the content is certified to have come from the source it claims to come from. So ... basically ... better not to use multicast for anything you really might have any security issues with. Fine for broadcasting a video, not so fine for a kernel update.
See the work of the IETF MIKEY working group.
He won't like it. He hates everything. Cheers, -- jra
On Wed, 4 May 2011, George Bonser wrote:
SSM with encryption?
Well, certainly, but source address can be very easily spoofed with a UDP multicast stream. Now that could be mitigated with a lot of network configuration rules but something is needed that just works without all that.
It's harder to effectively use spoofed source addresses in multicasting because of RPF. When you couple it with SSM you're forcing the attacker to either use multiple injection points, or gain access to a router close to the real source address. Couple that with encryption and you're denying spoofed addresses as an effective intrusion venue for large groups of viewers listening to a specific SSM source. Perfect is the enemy of good. Antonio Querubin e-mail: tony@lavanauts.org xmpp: antonioquerubin@gmail.com
----- Original Message -----
From: "George Bonser" <gbonser@seven.com>
So using multicast for things like software updates to computers over the general internet to the general public probably isn't going to work. Encryption is also an issue because it doesn't really work well over multicast. How do I encrypt something in a way that anyone can decrypt but nobody can duplicate? If I have a separate stream per user, that is easy. If I have one stream for all users, that is harder. The answer is probably in some sort of digital signature but not really encryption.
Um, yeah; that'd be private key digital signature.
Using public/private key encryption over multicast, I would have to distribute the private key so others could decrypt the content. If they have the private key, they can generate a public key to use to generate content.
Encryption is probably overkill anyway. What is needed is a mechanism simply to say that the content is certified to have come from the source it claims to come from. So ... basically ... better not to use multicast for anything you really might have any security issues with. Fine for broadcasting a video, not so fine for a kernel update.
Nah; you're overthinking it. Signed updates solve the problem just fine. Note that Linux (SuSE/YAST/YOU) does this already. But you *are* expanding the attack surface, and the signature/PKI infrastructure has to be correspondingly more robust. Cheers, -- jra
On 5/4/2011 12:26 PM, Tim Franklin wrote:
I think that George's POV -- which is also mine -- is that as the world shifts, the percentage of video distribution which is amenable to multicast, and not well served by unicast, is likely to grow, and it would be a Good Idea to be ready for that situation already when it arrives. Really? If anything, I'd say quite the opposite. Watching media in the time-slot that someone else has decided on is *so* 20th-century - I can't remember the last time I sat down to actively watch a programme in its original transmission slot. (As opposed to having the TV on as background, e.g. 15 minutes of breakfast news in the morning). I guess multicast to a recording application (or appliance) might work - but essentially my requirement is strongly skewed towards video-on-demand.
I have absolutely zero interest in sport of any kind though - I'm given to understand there's quite a high demand for live viewing of that.
Regards, Tim.
I agree, I think less and less content will be multicast with live events (like sports) being the notable exception. Having said that I think that multicast will increase in importance as more live events move into the remotely viewable venue. There is a huge market for concerts, live pays, comedy, and other content that just isn't available right now. The viewing market will continue to fragment requiring more sources of content than are available today. In short the percentage of video sent as multicast will decrease (IMO) over time but the overall volume will increase as total video content as IP greatly expands. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05/05/2011, at 2:53 AM, Scott Helms wrote:
On 5/4/2011 12:26 PM, Tim Franklin wrote:
I think that George's POV -- which is also mine -- is that as the world shifts, the percentage of video distribution which is amenable to multicast, and not well served by unicast, is likely to grow, and it would be a Good Idea to be ready for that situation already when it arrives. Really? If anything, I'd say quite the opposite. Watching media in the time-slot that someone else has decided on is *so* 20th-century - I can't remember the last time I sat down to actively watch a programme in its original transmission slot. (As opposed to having the TV on as background, e.g. 15 minutes of breakfast news in the morning). I guess multicast to a recording application (or appliance) might work - but essentially my requirement is strongly skewed towards video-on-demand.
I have absolutely zero interest in sport of any kind though - I'm given to understand there's quite a high demand for live viewing of that.
Regards, Tim.
I agree, I think less and less content will be multicast with live events (like sports) being the notable exception. Having said that I think that multicast will increase in importance as more live events move into the remotely viewable venue. There is a huge market for concerts, live pays, comedy, and other content that just isn't available right now. The viewing market will continue to fragment requiring more sources of content than are available today. In short the percentage of video sent as multicast will decrease (IMO) over time but the overall volume will increase as total video content as IP greatly expands.
--
Many years ago I was the MCI side of the Real Broadcast Network. Real Networks arranged to broadcast a Rolling Stones concert. We had the ability to multicast on the Mbone and unicast from Real Networks caches. We figured that we'd get a hit rate of 70% multicast (those who wanted to see the event as it happened) and 30% unicast (those who would wait and watch it later). The data we got back was the exact opposite of what we'd expected (30% multicast, 70% unicast) with an average skew being around 30 minutes (on average unicasters started viewing less than 30 minutes after the event began). Events like these formed my opinion that while multicast wouldn't be a ubiquitous transport, it would be a very important (our Real Networks caches picked the event up off the Mbone) tool for providers to use. The most ambitious use of multicast I'm aware of is AT&T's UVerse network which multicasts (SS) from two head-ends all the way to the set top box in a home. But this is confined to the AT&T network and UVerse is arguably a "me-too" offering to compete with Time Warner Cable and others. jy -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) iF4EAREIAAYFAk3Bz/gACgkQxvthcni5E28/zgD/Rn/+ow/ibdZ3k2MyDiWv0TJt Mnj4wcbLpCjSaweCsywBAIIHGy9XLRjCI/R1A82qiocx4uSuqXmWU9CQ/kyWn85c =9nb5 -----END PGP SIGNATURE-----
On 05/05/11 00:15, Jeff Young wrote:
The most ambitious use of multicast I'm aware of is AT&T's UVerse network which multicasts (SS) from two head-ends all the way to the set top box in a home. But this is confined to the AT&T network and UVerse is arguably a "me-too" offering to compete with Time Warner Cable and others.
Telefonica has a similar multicast deployment in its Spanish network, marketed as Imagenio, so this proves that multicast can be quite useful within a provider's own network. Too bad the economic incentives are not so clear/inexistent for transit networks. -Lorand Jakab
jy
Many years ago I was the MCI side of the Real Broadcast Network. Real Networks arranged to broadcast a Rolling Stones concert. We had the ability to multicast on the Mbone and unicast from Real Networks caches. We figured that we'd get a hit rate of 70% multicast (those who wanted to see the event as it happened) and 30% unicast (those who would wait and watch it later).
You do realize that unicast from Real Networks caches *IS* multicast, just not IP Multicast. Akamai runs a very large and successful multicast network which shows that there is great demand for multicast services, just not the low level kind provided by IP Multicast. In fact, the most important use for IP Multicast is to work around the problem of the "best route". In the financial industry, they don't want their traffic to take the best route, because that creates a chain of single points of failure. So instead, they build two multicast trees, send a copy of each packet into each tree, and arrange that the paths which the trees use are entirely separate. That means separacy of circuits and routers and switches. -- Michael Dillon
On 08/05/2011, at 4:10 PM, Michael Dillon <wavetossed@googlemail.com> wrote:
Many years ago I was the MCI side of the Real Broadcast Network. Real Networks arranged to broadcast a Rolling Stones concert. We had the ability to multicast on the Mbone and unicast from Real Networks caches. We figured that we'd get a hit rate of 70% multicast (those who wanted to see the event as it happened) and 30% unicast (those who would wait and watch it later).
You do realize that unicast from Real Networks caches *IS* multicast, just not IP Multicast. Akamai runs a very large and successful multicast network which shows that there is great demand for multicast services, just not the low level kind provided by IP Multicast.
In fact, the most important use for IP Multicast is to work around the problem of the "best route". In the financial industry, they don't want their traffic to take the best route, because that creates a chain of single points of failure. So instead, they build two multicast trees, send a copy of each packet into each tree, and arrange that the paths which the trees use are entirely separate. That means separacy of circuits and routers and switches.
-- Michael Dillon
In 1997, Real Networks caches were sending unicast. If they now operate differently I'm not aware (Real dumped the relationship in the DSL heyday to chase eyeballs -- iMCI was a backbone). But you've got one over on me, I've never heard of Akamai's "multicast" and given that they don't run a backbone to my knowledge it sounds as if they're using their server installs to route packets or have an interesting way of source routing or tunneling multiple streams of the same data through ISP networks. As for the financial industry I was only aware of some of the reliable mcast software in use to push ticker information to trading desks. All very interesting but the point was that the world of entertainment video consumption has long since become on-demand; many of the points being made for the use of IP multicast as a pseudo-broadcast mechanism have been made before (and will be made again). I personally think P2P is a much more interesting topic for (legally) distributing video these days and P4P may even solve the inter provider problem that multicast never seemed to crack. jy
----- Original Message -----
From: "Michael Dillon" <wavetossed@googlemail.com>
You do realize that unicast from Real Networks caches *IS* multicast, just not IP Multicast. Akamai runs a very large and successful multicast network which shows that there is great demand for multicast services, just not the low level kind provided by IP Multicast.
We're gonna have to agree to disagree on the definition of "multicast" then, I guess, Mike. Cause my definition is "only one stream of it passes through each interface of a given router", and I expect that doesn't fit the situation you're talking about. Cheers, -- jra
On Wed, May 4, 2011 at 12:26 PM, Tim Franklin <tim@pelican.org> wrote:
I think that George's POV -- which is also mine -- is that as the world shifts, the percentage of video distribution which is amenable to multicast, and not well served by unicast, is likely to grow, and it would be a Good Idea to be ready for that situation already when it arrives.
Really? If anything, I'd say quite the opposite. Watching media in the time-slot that someone else has decided on is *so* 20th-century - I can't remember the last time I sat down to actively watch a programme in its original transmission slot. (As opposed to having the TV on as background, e.g. 15 minutes of breakfast news in the morning). I guess multicast to a recording application (or appliance) might work - but essentially my requirement is strongly skewed towards video-on-demand.
I have absolutely zero interest in sport of any kind though - I'm given to understand there's quite a high demand for live viewing of that.
Regards, Tim.
Content can still be multicasted to the edge caching servers, for near-real-time updates, that you then may visit/view on-demand with your favorite unicast client Charles
Absolutely, multicast inside of a provider network is critical for feeding local caches. This is a common approach in IPTV networks supporting VOD via multiple headends.
Content can still be multicasted to the edge caching servers, for near-real-time updates, that you then may visit/view on-demand with your favorite unicast client
Charles
-- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------
Content can still be multicasted to the edge caching servers, for near-real-time updates, that you then may visit/view on-demand with your favorite unicast client
Charles
Yep. That gives a hybrid approach that still greatly reduces the load on the ultimate content source. One stream for all. Individual providers could then hold the content for unicast distribution within their net or the broadcast provider could even provide the server collocated at the eyeball network. And as you mention, as people shift to using the Internet for stuff that was traditionally the domain of broadcast traffic anyway, the same broadcast concepts would still apply as being a good means of sending the traffic. It would actually be rather simple with tools that are available right now. Maybe content distribution using UFTP http://www.tcnj.edu/~bush/uftp.html and then unicast to the end user from those systems. But for major events or things like content that is normally a broadcast channel (e.g. cable news), straight multicast all the way to the user is probably best, in my opinion.
On Fri, Apr 29, 2011 at 4:40 PM, Tim Durack <tdurack@gmail.com> wrote:
Multicast is a great technical solution in search of a good business problem.
It's a useful replacement for broadcast on a local link. It's of limited utility elsewhere. On Fri, Apr 29, 2011 at 5:21 PM, George Bonser <gbonser@seven.com> wrote:
Multicast is perfect for a live event. Unicast is best for "on demand" viewing of something.
A layered cache implemented via unicast would work better and enable local fills for lost packets too. More, it sits to the side of the routers rather than in line, so it allows your routers to focus on what they do well: routing unicast packets. Some time ago I sketched out a notion for a layered opportunistic caching system that finds its nearest caches via anycast and validates the cached data via a very small signature stream from the original source. Even if your viewing is off-sync with others using the caches in your hierarchy the probability of bandwidth savings increases rapidly with the popularity of the content. The idea is that you deploy these caches as deep in your system as is cost effective. Regionally. The local CO. In the box with the neighborhood fiber terminal if you find the traffic savings beats the equipment cost. And of course such a cache system could work well for popular non-streamed content as well. Never quite linked up with someone interested in seeing an implementation though... Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Wed, 04 May 2011 18:20:09 EDT, William Herrin said:
And of course such a cache system could work well for popular non-streamed content as well.
Never quite linked up with someone interested in seeing an implementation though...
I suspect to generate interest, it would have to be demonstrably better than just plopping a BitTorrent cache in your network.
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...)
----- Original Message -----
From: "Ryan Malayter"
On Apr 28, 11:14 pm, Jay Ashworth wrote:
(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.
----- Original Message -----
From: "George Bonser" <gbonser@seven.com>
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.
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
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?
On Friday, April 29, 2011 05:16:51 PM George Bonser wrote:
But if "broadcast" events over the internet are treated the same as "broadcast" events over RF, who cares?
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.
On Friday, April 29, 2011 03:37:04 PM Jay Ashworth wrote:
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").
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.
participants (36)
-
Antonio Querubin -
Charles Morris -
Chris Adams -
Dan White -
Daniel Roesen -
Daniel Staal -
david raistrick -
David Sparro -
George Bonser -
Jared Mauch -
Jay Ashworth -
Jeff Wheeler -
Jeff Young -
Jeffrey S. Young
-
Joel Jaeggli -
John Levine -
Lamar Owen -
Leigh Porter -
Leo Bicknell -
Loránd Jakab -
Martin Millnert -
Michael Dillon -
Michael Painter -
Octavio Alvarez -
Patrick W. Gilmore -
Robert Bonomi -
Rubens Kuhl -
Saku Ytti -
Scott Helms -
Silas Moeckel -
Simon Lockhart -
Steven Bellovin -
Tim Durack -
Tim Franklin -
Valdis.Kletnieks＠vt.edu -
William Herrin