Sunday traffic curiosity

Hugo Slabbert hugo at slabnet.com
Mon Mar 23 00:32:21 UTC 2020


I think that's the thing:
Drop cache boxes inside eyeball networks; fill the caches during off-peak;
unicast from the cache boxes inside the eyeball provider's network to
subscribers.  Do a single stream from source to each "replication point"
(cache box) rather than a stream per ultimate receiver from the source,
then a unicast stream per ultimate receiver from their selected
"replication point".  You solve the administrative control problem since
the "replication point" is an appliance just getting power & connectivity
from the connectivity service provider, with the appliance remaining under
the administrative control of the content provider.

It seems to be good enough to support business models pulling in billions
of dollars a year.

This does require the consumption of the media to be decoupled from the
original distribution of the content to the cache, obviously, hence the
live sports mismatch.  But it seems this catches enough of the use cases
and bandwidth demands, and to have won the "good enough" battle vs.
inter-domain multicast.

I would venture there are large percentage increases now in realtime use
cases as Zoom & friends take off more, but the bulk of the
anecdotal evidence thus far seems to indicate absolute traffic levels to
largely be below historical peaks from exceptional events (large
international content distribution events).

-- 
Hugo Slabbert       | email, xmpp/jabber: hugo at slabnet.com
pgp key: B178313E   | also on Signal


On Sun, Mar 22, 2020 at 3:51 PM Mark Tinka <mark.tinka at seacom.mu> wrote:

>
>
> On 23/Mar/20 00:19, Randy Bush wrote:
>
> >
> > add to that it is the TV model in a VOD world.  works for sports, maybe,
> > not for netflix
>
> Agreed - on-demand is the new economy, and sport is the single thing
> still propping up the old economy.
>
> When sport eventually makes into the new world, linear TV would have
> lost its last legs.
>
> Mark.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200322/244ae54c/attachment.html>


More information about the NANOG mailing list