Re: The 100 Gbit/s problem in your network

[Jeroen Massar <jeroen () massar ch>]

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:
> >    https://marcel.wanda.ch/Fuzzycast/
>
> (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:

On 2013-02-08 16:17 , Adam Vitkovsky wrote:
> 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