Multicast is dead. Feel free to disagree. :-)
Tim:
Multicast will never be dead.
With ever raising bandwidth needs we'll always welcome a distribution method
that allows us to pass the same data least times over the least number of
links.
We all remember the spikes in BW demands when the
That's not the general case, however. That's a set of specialized videos =
where
you know you will have a large number of consumers at each site viewing =
the
same video content.
Kind of like the special cases you need in order for multicast to
work out, hey?
So it looks like the Internet
On 02/11/2013 03:52 PM, Patrick W. Gilmore wrote:
One of us has a different dictionary than everyone else.
I'm not sure it's different dictionaries, I think you're talking past
each other.
Video on demand and broadcast are 2 totally different animals. For VOD,
multicast is not a good
Just to clarify, Patrick is right here.
Assumptions:
All the movies is 120 minuters long. Each movie has an average bitrate
of 50 Mbit/s.
(50 Mbit/s / 8 (bits) * 7 200 (2 hours) / 1000 (MB) = 45 GB).
That means that the storage capacity for the movies is going to be:
10 000 000 * 45 (GB)
You could make far more connecting your awesome prediction software to the
stock market, than using it to figure out what specific content people are
going to watch to cache before they decide to watch it...
And if you don't have said awesome software, then how do you propose to
limit the
On 12/02/13 14:14, fredrik danerklint wrote:
Just to clarify, Patrick is right here.
Assumptions:
All the movies is 120 minuters long. Each movie has an average bitrate
of 50 Mbit/s.
(50 Mbit/s / 8 (bits) * 7 200 (2 hours) / 1000 (MB) = 45 GB).
That means that the storage capacity for
And if you don't have said awesome software, then how do you propose to
limit the bandwidth need for the cache so you aren't burning more bandwidth
than your hit rate, which is what everyone is trying to ask you (or more
accurately, explain to you)?
Without the concept of TLMC, I don't know.
I
On Feb 12, 2013, at 01:06 , Doug Barton do...@dougbarton.us wrote:
On 02/11/2013 03:52 PM, Patrick W. Gilmore wrote:
One of us has a different dictionary than everyone else.
I'm not sure it's different dictionaries, I think you're talking past each
other.
No, it's definitely different
On Mon, Feb 11, 2013 at 10:05 PM, Tim Durack tdur...@gmail.com wrote:
Multicast is dead. Feel free to disagree. :-)
Tim:
I really wish I could agree! It would have saved me some time dealing with
it.
There is the argument of alternative bit rates, compression, etc., but HD
streams are
I really wish I could agree! It would have saved me some time dealing with
it.
There is the argument of alternative bit rates, compression, etc., but HD
streams are assumed[1] at 15 Mbps.
At 100Gbps, I can do max 6826 streams of HD streaming. Multicast
deployments laugh at this
The only time real-time per se matters is if you're playing the same content
on multiple screens and *synchronization* matters.
And there's the HFT where real-time really does matter :)
adam
I don't see a need for multicast to work in Internet scale, ever.
adam
-Original Message-
From: Saku Ytti [mailto:s...@ytti.fi]
Sent: Friday, February 08, 2013 6:02 PM
To: nanog@nanog.org
Subject: Re: The 100 Gbit/s problem in your network
On (2013-02-08 14:15 +), Aled Morris wrote
On (2013-02-11 11:58 +0100), Adam Vitkovsky wrote:
The only time real-time per se matters is if you're playing the same content
on multiple screens and *synchronization* matters.
And there's the HFT where real-time really does matter :)
I think most of HFT crowd are buying into low-latency
February 2013 11:03, Adam Vitkovsky adam.vitkov...@swan.sk wrote:
I don't see a need for multicast to work in Internet scale, ever.
adam
-Original Message-
From: Saku Ytti [mailto:s...@ytti.fi]
Sent: Friday, February 08, 2013 6:02 PM
To: nanog@nanog.org
Subject: Re: The 100 Gbit/s
On (2013-02-11 12:16 +), Aled Morris wrote:
I don't see why, as an ISP, I should carry multiple, identical, payload
packets for the same content. I'm more than happy to replicate them closer
to my subscribers on behalf of the content publishers. How we do this is
the question, i.e. what
On 11/02/2013 12:16, Aled Morris wrote:
I don't see why, as an ISP, I should carry multiple, identical, payload
packets for the same content. I'm more than happy to replicate them closer
to my subscribers on behalf of the content publishers. How we do this is
the question, i.e. what form the
On 2/11/2013 7:23 AM, Saku Ytti wrote:
On (2013-02-11 12:16 +), Aled Morris wrote:
I don't see why, as an ISP, I should carry multiple, identical, payload
packets for the same content. I'm more than happy to replicate them closer
to my subscribers on behalf of the content publishers. How
On 2/11/13 9:32 AM, ML wrote:
On 2/11/2013 7:23 AM, Saku Ytti wrote:
On (2013-02-11 12:16 +), Aled Morris wrote:
I don't see why, as an ISP, I should carry multiple, identical, payload
packets for the same content. I'm more than happy to replicate them
closer
to my subscribers on behalf
On 11-Feb-13 12:25, Mark Radabaugh wrote:
On 2/11/13 9:32 AM, ML wrote:
Any eyeball network that wants to support multicast should peer with
the content players(s) that support it. Simple!
Just another reason to make the transit only networks even more
irrelevant.
The big issue is that the
Multicast _is_ useful for filling the millions of DVRs out there with
broadcast programs and for live events (eg. sports). A smart VOD system
would have my DVR download the entire program from a local cache--and
then play it locally as with anything else I watch. Those caches could
be
- Original Message -
From: Stephen Sprunk step...@sprunk.org
Multicast _is_ useful for filling the millions of DVRs out there with
broadcast programs and for live events (eg. sports). A smart VOD system
would have my DVR download the entire program from a local cache--and
then play
On Mon, Feb 11, 2013 at 3:01 PM, Scott Helms khe...@zcorum.com wrote:
If you're a large MSO (say top 15)
then I can see it with today's technology, but even those guys seem to be
moving in other directions to get out of the provider controlled set top
box model.
really? verizon still wants to
These technologies are being unified by DASH in the MPEG/ISO standards bodies.
Then we have to hope that we will see this implemented in
Traffic Server, Squid, Varnish, so that everybody can benefit
from this.
--
//fredan
The Last Mile Cache - http://tlmc.fredan.se
Lol, I didn't say all of them were doing that yet.
On Feb 11, 2013 3:50 PM, Christopher Morrow morrowc.li...@gmail.com
wrote:
On Mon, Feb 11, 2013 at 3:01 PM, Scott Helms khe...@zcorum.com wrote:
If you're a large MSO (say top 15)
then I can see it with today's technology, but even those
I meant to add in more info, but my mobile Gmail client betrayed me.
On Mon, Feb 11, 2013 at 3:59 PM, Scott Helms khe...@zcorum.com wrote:
Lol, I didn't say all of them were doing that yet.
On Feb 11, 2013 3:50 PM, Christopher Morrow morrowc.li...@gmail.com
wrote:
On Mon, Feb 11, 2013 at
On Feb 11, 2013, at 14:11 , Stephen Sprunk step...@sprunk.org wrote:
On 11-Feb-13 12:25, Mark Radabaugh wrote:
On 2/11/13 9:32 AM, ML wrote:
Any eyeball network that wants to support multicast should peer with
the content players(s) that support it. Simple!
Just another reason to make the
On Feb 11, 2013, at 18:52 , Patrick W. Gilmore patr...@ianai.net wrote:
On Feb 11, 2013, at 14:11 , Stephen Sprunk step...@sprunk.org wrote:
Multicast _is_ useful for filling the millions of DVRs out there with
broadcast programs and for live events (eg. sports). A smart VOD system
would
Multicast _is_ useful for filling the millions of DVRs out there with
broadcast programs and for live events (eg. sports). A smart VOD =
system
would have my DVR download the entire program from a local cache--and
then play it locally as with anything else I watch. Those caches =
could
On Feb 12, 2013, at 8:11 AM, Joe Greco wrote:
The real question is: how will video evolve?
My guess is that most of it will become synthetic, generated programmatically
from local primitives via algorithmic instructions, much in the way that
multiplayer 3D FPS games handle such things today.
On Mon, Feb 11, 2013 at 8:11 PM, Joe Greco jgr...@ns.sol.net wrote:
Multicast _is_ useful for filling the millions of DVRs out there with
broadcast programs and for live events (eg. sports). A smart VOD =
system
would have my DVR download the entire program from a local cache--and
On 2/11/2013 11:05 PM, Tim Durack wrote:
Multicast is dead. Feel free to disagree. :-) Tim:
Multicast is a vendor selling point, as you essentially need a coherent
end-to-end solution to get it to work PROPERLY. Of course if it does
not work PROPERLY, it will still largely work, albeit
That's not the general case, however. That's a set of specialized videos where
you know you will have a large number of consumers at each site viewing the
same video content.
Owen
On Feb 11, 2013, at 20:46 , Ryan Malayter malay...@gmail.com wrote:
You're missing the entire point: all web
On 02/11/2013 03:52 PM, Patrick W. Gilmore wrote:
One of us has a different dictionary than everyone else.
I'm not sure it's different dictionaries, I think you're talking past
each other.
Video on demand and broadcast are 2 totally different animals. For VOD,
multicast is not a good fit,
On Feb 9, 2013, at 6:45 AM, fredrik danerklint fredan-na...@fredan.se wrote:
No. Streaming from services, like Netflix, HBO, etc..., is what's
coming. We need to prepare for the bandwidth they are going to be
using.
Then work on your HTTP caching infrastructure. All these services already
How about buy the movies in question, convert them to MP4, install a media
server on a local box and configure Xbox, tablet, smart-phone, whatever to
access the media server?
No. Streaming from services, like Netflix, HBO, etc..., is what's
coming. We need to prepare for the bandwidth they
But it has become unclear what your fundamental premise and argument are,
by this point in the game.
See the subject of this thread?
Is it: it is bad that content providers choose a business and technical
model wherein local in-home transparent caching proxies won't work?
No, it's not.
--
- Well, as it turns out, we don't have that kind of a problem.
- You don't?
- No, we do not have that kind of a problem in our network.
We have plenty of bandwidth available to our customers,
thank-you-every-much.
- Do you have, just to make an example, about 10 000 customers
in a
Akamai.
The actual example is to watch the Super Bowl. :-)
fredrik danerklint fredan-na...@fredan.se wrote:
- Well, as it turns out, we don't have that kind of a problem.
- You don't?
- No, we do not have that kind of a problem in our network.
We have plenty of bandwidth available to our
Multicast
Aled
On 8 February 2013 13:42, Jay Ashworth j...@baylink.com wrote:
Akamai.
The actual example is to watch the Super Bowl. :-)
fredrik danerklint fredan-na...@fredan.se wrote:
- Well, as it turns out, we don't have that kind of a problem.
- You don't?
- No, we do not
A movie is static. The content does not change despite how many times
you watch it.
Multicast
Can be useful for live events, like news or sports. I give you that.
--
//fredan
to watch the latest Quad-HD movie
Multicast
-I'm afraid it has to be unicast so that people can pause/resume anytime
they need to go... well you know what I mean
adam
On 2013-02-08 15:39 , Adam Vitkovsky wrote:
to watch the latest Quad-HD movie
Multicast
-I'm afraid it has to be unicast so that people can pause/resume anytime
they need to go... well you know what I mean
Works fine too with multicast, for instance with FuzzyCast:
to watch the latest Quad-HD movie
Multicast
-I'm afraid it has to be unicast so that people can pause/resume anytime
they need to go... well you know what I mean
Works fine too with multicast, for instance with FuzzyCast:
https://marcel.wanda.ch/Fuzzycast/
(I did notice that this was
Works fine too with multicast, for instance with FuzzyCast:
Well yes but you need to make some compromises on behalf of user experience.
And 30sec delay is unacceptable.
You can use 10 cheaper VOD servers closer to eyeballs making it 1000
customers abusing the particular portion of the local
On 2013-02-08 16:13 , fredrik danerklint wrote:
to watch the latest Quad-HD movie
Multicast
-I'm afraid it has to be unicast so that people can pause/resume anytime
they need to go... well you know what I mean
Works fine too with multicast, for instance with FuzzyCast:
You really think people did not have problems with the 1mbit links they
had back then?
Yes, I do.
And you really think that we won't have problems with
Zillion-HD or whatever they will call it in another 20 years?
I think that this is something I'm trying to say, with the creation of
this
On 2/8/13 5:23 AM, fredrik danerklint wrote:
- Well, as it turns out, we don't have that kind of a problem.
- You don't?
- No, we do not have that kind of a problem in our network.
We have plenty of bandwidth available to our customers,
thank-you-every-much.
- Do you have, just to make an
The media market has fragmented, so unless we're talking about the first
week in February in the US it's not all from one source or 3 or 5.
Explain further. I did not get that.
So far the most common delivery format for quad HD content online rings
in at around 20Mb/s so you're not
On 2013-02-08 17:03 , fredrik danerklint wrote:
You really think people did not have problems with the 1mbit links they
had back then?
Yes, I do.
And you really think that we won't have problems with
Zillion-HD or whatever they will call it in another 20 years?
I think that this is
- Original Message -
From: fredrik danerklint fredan-na...@fredan.se
The media market has fragmented, so unless we're talking about the
first week in February in the US it's not all from one source or 3 or 5.
Explain further. I did not get that.
Joel is saying that the problem
Perhaps the solution is to have a 400Gbit/s problem :-)
http://newswire.telecomramblings.com/2013/02/france-telecom-orange-and-alcatel-lucent-deploy-worlds-first-live-400-gbps-per-wavelength-optical-link/
On (2013-02-08 14:15 +), Aled Morris wrote:
Multicast
I don't see multicast working in Internet scale.
Essentially multicast means core is flow-routing. So we'd need some way to
decide who gets to send their content as multicast and who are forced to
send unicast.
It could create de-facto
Can you set something up for the week of the 18th?
fredrik danerklint fredan-na...@fredan.se wrote:
The media market has fragmented, so unless we're talking about the first
week in February in the US it's not all from one source or 3 or 5.
Explain further. I did not get that.
So far the
I do have an suggestion for how to solve this. See my message yesterday
to the mailing list.
Ah, I get it, you are trying to get people to acknowledge the
non-existence of your tool that does what every transparent HTTP proxy
has been doing for years! ;)
Where exactly do you put those
My understanding is there is no appreciable amount of QHD programming
available to watch anyway, and certainly nothing a) in English b) that
isn't sports.
Why wouldn't you like to solve the problem before it can happen?
(I'm talk about static content here, not live events).
--
//fredan
Again: Akamai. See also Limelight, etc...
fredrik danerklint fredan-na...@fredan.se wrote:
My understanding is there is no appreciable amount of QHD programming
available to watch anyway, and certainly nothing a) in English b)
that
isn't sports.
Why wouldn't you like to solve the problem
On 2/8/13 8:23 AM, fredrik danerklint wrote:
The media market has fragmented, so unless we're talking about the first
week in February in the US it's not all from one source or 3 or 5.
Explain further. I did not get that.
The superbowl is the first sunday in feb, it pulls a 75 share of the tv
How does Akamai or Limelight or any other CDN, allow your customers as
an ISP to cache the content at their home, in their own cache server?
Again: Akamai. See also Limelight, etc...
fredrik danerklint fredan-na...@fredan.se wrote:
My understanding is there is no appreciable amount of QHD
On 2/8/13 9:02 AM, Saku Ytti wrote:
On (2013-02-08 14:15 +), Aled Morris wrote:
Multicast
I don't see multicast working in Internet scale.
Essentially multicast means core is flow-routing. So we'd need some way to
decide who gets to send their content as multicast and who are forced to
About 40 - 50 Mbit/s. Not bad at all.
Downloading software does not have to be in real-time, like watching
a movie, does.
In both cases it's actually rather convenient if it's as fast as
possible,
Yes. What I would like to have is to allow the access switch, which a
customer for an ISP is
On 2/8/13 9:46 AM, fredrik danerklint wrote:
About 40 - 50 Mbit/s. Not bad at all.
Downloading software does not have to be in real-time, like watching
a movie, does.
In both cases it's actually rather convenient if it's as fast as
possible,
Yes. What I would like to have is to allow the
- Original Message -
From: fredrik danerklint fredan-na...@fredan.se
allow my customers as an ISP to cache the content at their home.
Do you *mean* their home -- an end-user residence?
Yes, I do *mean* that.
As in you, Jay, should be allowed to run your own cache server in
allow my customers as an ISP to cache the content at their home.
Do you *mean* their home -- an end-user residence?
Yes, I do *mean* that.
As in you, Jay, should be allowed to run your own cache server in your
home (Traffic Server is the one that I'm using in the TLMC concept).
Wouldn't you
- Original Message -
From: fredrik danerklint fredan-na...@fredan.se
It would do little good; my hit rate on such a cache would be
unlikely to be high enough to merit the traffic to keep it charged.
(Children watching a movie only once? Not a chance. It's more like
unlimited
, February 8, 2013 2:58:42 PM
Subject: Re: The 100 Gbit/s problem in your network
allow my customers as an ISP to cache the content at their home.
Do you *mean* their home -- an end-user residence?
Yes, I do *mean* that.
As in you, Jay, should be allowed to run your own cache server in your
On Fri, 2013-02-08 at 10:50 -0800, joel jaeggli wrote:
On 2/8/13 9:46 AM, fredrik danerklint wrote:
About 40 - 50 Mbit/s. Not bad at all.
Downloading software does not have to be in real-time, like watching
a movie, does.
In both cases it's actually rather convenient if it's as fast as
On Fri, Feb 8, 2013 at 3:58 PM, Laurent GUERBY laur...@guerby.net wrote:
The problem with increasing capacity is that it opens up captive
eyeballs to innovative services from outside: monopoly operators will
prefer to deal with CDN providers the like and keep control.
there are ways to offer
67 matches
Mail list logo
