> 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 th
> 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 path
On Mon, Feb 11, 2013 at 10:05 PM, Tim Durack 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 assumed[1] at 1
On Feb 12, 2013, at 01:06 , Doug Barton 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 dictionaries.
I
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 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 the
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 bandwidt
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)
> 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
> 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 Intern
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, c
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 wrote:
> You're missing the entire point: all web caches *already* work w
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 ineffi
On Mon, Feb 11, 2013 at 8:11 PM, Joe Greco 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
> > > then
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.
> > 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
On Feb 11, 2013, at 18:52 , "Patrick W. Gilmore" wrote:
> On Feb 11, 2013, at 14:11 , Stephen Sprunk 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 entir
On Feb 11, 2013, at 14:11 , Stephen Sprunk 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 trans
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 wrote:
> Lol, I didn't say all of them were doing that yet.
> On Feb 11, 2013 3:50 PM, "Christopher Morrow"
> wrote:
>
>> On Mon, Feb 11, 2013 at 3:01 PM, Scott Helms wrote:
>> >
Lol, I didn't say all of them were doing that yet.
On Feb 11, 2013 3:50 PM, "Christopher Morrow"
wrote:
> On Mon, Feb 11, 2013 at 3:01 PM, Scott Helms 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 d
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
On Mon, Feb 11, 2013 at 3:01 PM, Scott Helms 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 sell the hell
- Original Message -
> From: "Stephen Sprunk"
> 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
> 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 p
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
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 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 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
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. w
l technical solution.
Aled
On 11 February 2013 11:03, Adam Vitkovsky 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:
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-lat
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
>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
On Feb 9, 2013, at 6:45 AM, fredrik danerklint 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 use a
proprietary fo
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.
-
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 a
On Fri, Feb 8, 2013 at 3:58 PM, Laurent GUERBY 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 vod/etc wi
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
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.
>>
- Original Message -
> From: "fredrik danerklint"
> > 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 number of times a
"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 y
- Original Message -
> From: "fredrik danerklint"
> > "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
> h
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 acce
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 con
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
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 wrote:
My understanding is there is no appreciable amount of QHD programming
available t
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
Again: Akamai. See also Limelight, etc...
fredrik danerklint 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 before it can ha
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
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 transpar
Can you set something up for the week of the 18th?
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.
>
>> So far the most common deliv
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-fact
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/
- Original Message -
> From: "fredrik danerklint"
> > 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 you posit: *ever
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
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 delivering
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
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 t
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:
>>
> 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 ac
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 d
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:
https://marcel.wa
> > 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
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
"Multicast"
Aled
On 8 February 2013 13:42, Jay Ashworth wrote:
> "Akamai".
>
> The actual example is "to watch the Super Bowl". :-)
>
> 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
"Akamai".
The actual example is "to watch the Super Bowl". :-)
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,
>
- 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 specifi
67 matches
Mail list logo
