|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
Date: Mon, 11 Feb 2013 09:32:32 -0500 From: ML <ml@kenweb.org> To: nanog@nanog.org In-Reply-To: <20130211122316.GA3686@pob.ytti.fi> Reply-To: ml@kenweb.org Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org 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.
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |