[160681] in North American Network Operators' Group
Re: The 100 Gbit/s problem in your network
daemon@ATHENA.MIT.EDU (Mark Radabaugh)
Mon Feb 11 13:24:32 2013
Date: Mon, 11 Feb 2013 13:25:26 -0500
From: Mark Radabaugh <mark@amplex.net>
To: nanog@nanog.org
In-Reply-To: <51190100.8030105@kenweb.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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 +0000), 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 "multi"-"casting" takes.
>>>
>>> It would be nice if we could take advantage of an inherent design of
>>> IP and
>>> the hardware it runs on, to duplicate the actual packets in-flow as
>>> near as
>>> is required to the destination.
>>>
>>> Installing L7 content delivery boxes or caches is OK, but doesn't
>>> seem as
>>> efficient as an overall technical solution.
>> As an overall technical solution Internet scale multicast simply does
>> not
>> work today.
>> If it did work, then our next hurdle would be, how to get tier1 to play
>> ball, they get money on bits transported, it's not in their best
>> interested
>> to reduce that amount.
>
> 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 customers don't want to watch simulcast
content. The odds of having two customers in a reasonably sized
multicast domain watching the same netflix movie at exactly the same
time frame in the movie is slim. Customers want to watch on time frames
of their own choosing. I don't see multicast helping at all in dealing
with the situation.
Mark
--
Mark Radabaugh
Amplex
mark@amplex.net 419.837.5015
