The 100 Gbit/s problem in your network

- 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 specific area, like an city/county or part of a
   city/county?

- Yes, of course!

- Does these customers have at least 10 Mbit/s connection to the
   Internet?

- Yes! Who do you think we are, like stupid! Haha!

- Could all those 10 000 customers, just to make it theoretical,
   hit the 'play'-button on their Internet-connected-TV, at the same
   time, to watch the latest Quad-HD movie?

- Yes. Oh wait a minute now! This is not fair! Damn. We're toast.

"Akamai".

The actual example is "to watch the Super Bowl". :slight_smile:

"Multicast"

Aled

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.

> 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

Works fine too with multicast, for instance with FuzzyCast:
  https://marcel.wanda.ch/Fuzzycast/

The only little snag with multicast is that it typically is only on the
last leg and it fails when a transit or simply multiple domains become
involved.

Greets,
Jeroen

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:
   Marcel Waldvogel: Fuzzycast Project Page

(I did notice that this was developed in 2001 - 2002!)

That works if you are only distributing Video on Demands content.

"32 seconds after the later, after the initial delay, enough data has been received such that playout can begin"

So we are back to the b..u..f..f..e..r..i..n..g.. thing, again?

If you also want, for example, to have the possibility to distribute software, (static content as well), can you do that with Fussycast?

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 access/aggregation
network.

adam

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:
   Marcel Waldvogel: Fuzzycast Project Page

(I did notice that this was developed in 2001 - 2002!)

You really think people did not have problems with the 1mbit links they
had back then? And you really think that we won't have problems with
Zillion-HD or whatever they will call it in another 20 years?

That works if you are only distributing Video on Demands content.

Thus the question becomes, for what would it not work?

"32 seconds after the later, after the initial delay, enough data has
been received such that playout can begin"

So we are back to the b..u..f..f..e..r..i..n..g.. thing, again?

If you also want, for example, to have the possibility to distribute
software, (static content as well), can you do that with Fussycast?

and:

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
access/aggregation network.

Read the documents and other related literature on that site a little
bit further: you can overcome those first couple of seconds by fetching
those 'quickly' using unicast. Yes, that does not make it a full
multicast solution, but the whole idea of multicast usage in these
scenarios: less traffic on the backbone. With this setup you only get
the hits for the first couple of seconds and after that they have it all
from multicast.

And one can of course employ strategies as used currently by for
instance UPC's Horizon TV boxes that already 'tune in' to the channel
that the user is likely going to zap to next, thus shaving off another
few bits there too...

Greets,
Jeroen

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

That works if you are only distributing Video on Demands content.

Thus the question becomes, for what would it not work?

If you also want, for example, to have the possibility to distribute
software, (static content as well), can you do that with Fussycast?

As I asked; Static content, like in files (*.zip, *.tar.gz, *.iso, etc...)

Read the documents and other related literature on that site a little
bit further: you can overcome those first couple of seconds by fetching
those 'quickly' using unicast.

Since you are back to the Unicast thing, and as you sad the problem
with the 1 Mbit/s links, I do think your question whould be:

How could we put the cache servers right next to our DSLAM:s, aggregation switches (or what ever you want to place them in your network) and have everything that's static content, cached?

I do have an suggestion for how to solve this. See my message yesterday to the mailing list.

- 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 specific area, like an city/county or part of a
  city/county?

- Yes, of course!

- Does these customers have at least 10 Mbit/s connection to the
  Internet?

- Yes! Who do you think we are, like stupid! Haha!

- Could all those 10 000 customers, just to make it theoretical,
  hit the 'play'-button on their Internet-connected-TV, at the same
  time, to watch the latest Quad-HD movie?

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.

So far the most common delivery format for quad HD content online rings in at around 20Mb/s so you're not delivering that to 10Mb/s customer(s).

On the other hand, two weekends ago I bought skyrim on steam and it was delivered, all 5.5GB of it in about 20 minutes. That's not instant gratification but it's acceptable.

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 that to 10Mb/s customer(s).

Isn't 20 Mbit/s more than 10 Mbit/s? (If so, we're taking about
10 000 customers * 20 Mbit/s = 200 000 Mbit/s or 200 Gbit/s).

On the other hand, two weekends ago I bought skyrim on steam and it was
delivered, all 5.5GB of it in about 20 minutes. That's not instant
gratification but it's acceptable.

About 40 - 50 Mbit/s. Not bad at all.

Downloading software does not have to be in real-time, like watching
a movie, does.

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

That works if you are only distributing Video on Demands content.

Thus the question becomes, for what would it not work?

If you also want, for example, to have the possibility to distribute
software, (static content as well), can you do that with Fussycast?

As I asked; Static content, like in files (*.zip, *.tar.gz, *.iso, etc...)

There is a difference in serving FriendsS01E01.mpg, FriendsS020E3.mkv
and FriendsS03.iso ??? Video On Demand is pretty static, perfect for
distributing with multicast. (now you will run out of multicast groups
in IPv4/Ethernet if you have a large amount of small files though, but
there are other protocols for that around)

[..]

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! :wink:

For that you do not need to do strange DNS-stealing hacks or
coordination with various parties, one only has to steal port 80.

For instance see this nice FAQ from 2002:
   Transparent Proxy with Linux and Squid mini-HOWTO

Fortunately quite a few content providers are moving to HTTPS so that
that can't happen anymore.

Greets,
Jeroen

From: "fredrik danerklint" <fredan-nanog@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 you posit: *everyone* wanting to watch
the same exact thing at the same exact time, only applies to live TV, and
these days, substantially the only thing that can pull anywhere *near*
that kind of share is the Super Bowl, which happens to occur the first
Sunday in February. Er, Febru-ANY. :slight_smile:

Isn't 20 Mbit/s more than 10 Mbit/s? (If so, we're taking about
10 000 customers * 20 Mbit/s = 200 000 Mbit/s or 200 Gbit/s).

Sure; he was just picking a nit about your specification of the customer
loops: those people aren't watching QHD anyway, so no sense in using it
as an exemplar.

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.

> On the other hand, two weekends ago I bought skyrim on steam and it
> was delivered, all 5.5GB of it in about 20 minutes. That's not instant
> gratification but it's acceptable.

About 40 - 50 Mbit/s. Not bad at all.

Downloading software does not have to be in real-time, like watching
a movie, does.

Real-time is not the constraint you're looking for. To deliver watchable
video, the average end-to-end transport bit rate must merely be higher than
the program encoding bitrate, with some extra overhead for the lack of real
QoS and other traffic on the link; receiver buffers help with this.

The only time real-time per se matters is if you're playing the same
content on multiple screens and *synchronization* matters.

Cheers,
-- jra

Perhaps the solution is to have a 400Gbit/s problem :slight_smile:
http://newswire.telecomramblings.com/2013/02/france-telecom-orange-and-alcatel-lucent-deploy-worlds-first-live-400-gbps-per-wavelength-optical-link/

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 monopolies, as new entries to the market wont have
their multicast carried, they cannot compete pricing wise with established
players who are carried.

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! :wink:

Where exactly do you put those transparent http proxy servers in
your network?

For that you do not need to do strange DNS-stealing hacks or
coordination with various parties, one only has to steal port 80.

There is two thing that The Last Mile Cache does _not_ do;

Steal either the DNS nor the port 80 part.

(I have to give it to you that it is a DNS solution part involved in
TLMC as well as a reverse proxy server).

It's an solution which does not force either the CSP (Content Service
Provider) nor the ISP to participate in TLMC. It will tough, allow a
customer of an ISP (which has to participate in TLMC in the first
place) to have it's own cache server at their home. (And yes, the CSP
needs to participate as well for it to work).

Fortunately quite a few content providers are moving to HTTPS so that
that can't happen anymore.

If you want your content cached at various ISP:s around the world,
encrypt the content, not the session.

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

Again: Akamai. See also Limelight, etc...

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 market, about the only thing that does so it's a pretty good example of all eyeballs facing the same direction, of course it's also available via terestrial broadcast, satellite, cable RF and so forth . other than that you talking about a couple of hundred of the most popular content items, followed by a very long tail worth of everything else. While I'm pretty sure somebody in my building watches glee for example or downloaded skyfall in the last week, I'm probably the only one to have streamed a canucks hockey game from 2 weeks ago last night in 1080p.

So far the most common delivery format for quad HD content online rings
in at around 20Mb/s so you're not delivering that to 10Mb/s customer(s).

Isn't 20 Mbit/s more than 10 Mbit/s? (If so, we're taking about
10 000 customers * 20 Mbit/s = 200 000 Mbit/s or 200 Gbit/s).

10Mb/s was your number not mine, my crystal ball is total garbage but I don't see delivery 20Mb/s streaming services as a dramatically different problem then delivering 6-8Mb/s streaming services is today.

On the other hand, two weekends ago I bought skyrim on steam and it was
delivered, all 5.5GB of it in about 20 minutes. That's not instant
gratification but it's acceptable.

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, That movie I bought 5 minutes ago from apple I might be streaming to my apple-tv (which has effectively negligible storage), or I might be dumping it on my ipad, in the later case the sooner it arrives the sooner that process is finished and I can unplug it. With the game download, with some exceptions like DLC's I can't start playing until it has arrived so fullfilment is very very important, come back tomorrow when it's done downloading loses you a lot of sales.