All things related to multicast

[Ray Soucy <>]

I never really gave AMT a look, but it seems like there has been some
work on the standard over the years:
http://tools.ietf.org/html/draft-ietf-mboned-auto-multicast-10

Is there any work on the implementation aside from UT Dallas?
http://cs.utdallas.edu/amt/

I certainly agree that if multicast is going to become more attractive
we need a way of reaching people who don't have access to global
multicast.

AMT seems like it would be an attractive solution to that, but I
really don't think this will ultimately work.

One of the reasons the R&E community can make use of multicast is that
it has very modest bandwidth requirements, not to mention the traffic
is often routed over R&E links (usually dark fiber) avoiding the silly
cost per Mb model.

Setting up an AMT relay at every I2 member, for example, would provide
access, but it wouldn't be much different than hosting a streaming
server at that point.  The bandwidth requirements would scale linearly
with client count and likely be using commercial bandwidth that is a
considerable cost for universities already.  At best AMT would become
a multicast CDN.

To throw some numbers here, say you have 100,000 viewers for an event
with a 20 Mb HD stream, even if you split it across 10 relays (which I
think we would be lucky to see) that's still 195 Gb per relay
(assuming equal distribution, which wouldn't be likely), so say a
"relay" would actually be a 200 server farm, assuming you could
actually get that much commercial bandwidth (most of us are sitting on
10 Gb or less of it)

The only way this works is if the relays are at the ISP's.  These are
the same ISP's who simply don't route global multicast, and to be
blunt, if it's done at the ISP level, a direct peering would be
preferable to something like AMT.

So I guess what I'm saying is I'm not sure AMT actually solves the
real problem.

It's basically just a way of turning multicast into unicast unless you
have a lot of relays, and the barriers preventing the deployment of
relays are the same barriers preventing the routing of global
multicast.  At that point, you might as well go with a streaming
server that can transcode the stream into something more manageable
and that can be viewed in the browser without the need to install
client applications.

This might actually be a better place for I2 to focus on getting
multicast content to the "outside":  A server that can take multicast
feeds, transcode, and provide live, low-bitrate, streams using HTML5.
Then have an I2 redirect server that would balance load across the
registered netcast nodes.

On Fri, Feb 25, 2011 at 11:45 AM, Leonard Giuliano 
<>
 wrote:
>
> I wouldn't declare the patient dead just yet.
>
> While mcast in general may be experiencing a peak of interest and
> deployment on VPN and video distribution networks, it is probably true
> that interest in interdomain (or more specifically Internet) mcast is
> currently at perhaps its nadir.  But there is something out there
> providing decent opportunity for hope- AMT.
>
> There are many obstacles for Internet mcast, but I would argue that the
> biggest by far is that mcast is an all-or-nothing solution.  Namely, it
> must be deployed on every L3 device between source and receiver.  Getting
> every router and fw on the Internet to support the protocols necessary to
> make mcast work has proven to be a pretty mountain to climb.  However, AMT
> solves this problem.  AMT allows you to automagically tunnel mcast traffic
> from the edge of the mcast-enabled network directly to end hosts on
> unicast-only networks.  With AMT, the content-audience chicken-and-egg
> problem goes away- the entire Internet can now be the potential audience.
>
> AMT has been around for a while, but what is relatively new is that there
> are real scalable implementations out there, and it's no longer just a
> science project.  Late last year, there was a big gaming event that used
> AMT to deliver Internet mcast:
>
> http://www.attinnovationspace.com/2010/11/23/first-ever-open-web-multicast-event/
>
> Getting a few AMT relays out on the Internet, having some more
> interesting content and perhaps some AMT GW implementations for
> Android/iPhone would help.  Maybe a World Multicast Day?
>
> For a description of the potential for Internet mcast and the role AMT can
> play:
>
> http://www.networkworld.com/news/tech/2011/010511-tech-update-next-gen-tv.html
>
>
>
> On Thu, 24 Feb 2011, Garry Peirce wrote:
>
> -) Using the frequency of messages on this list and working SAP entries as a
> -) rudimentary gauge, the level of interdomain v4 multicast work/content 
> seems
> -) low (not to mention v6 which is not yet possible for us).   I believe 
> that
> -) mcast has still yet to realize its value and I'm curious in hearing how
> -) others view and use inter/intradomain mcast.
> -)
> -) Mcast can be R&E differentiating value-add among ourselves and our
> -) participants.
> -)
> -)
> -)
> -) To give insight into our use, as a unit of the University System,
> -) Networkmaine operates Maine's statewide network (K-20, Research, 
> Libraries,
> -) Public Service).
> -)
> -) Within the University System, we currently make internal production use 
> of
> -) v4 mcast for ITV distance learning (including ~20 K12 sites) and on
> -) scattered wired subnets as needed for disk imaging.
> -)
> -) IPTV of commercial content is a wishful thought, but with cableTV 
> services
> -) contracted/maintained by other entities , raising interest tends to be an
> -) uphill battle.
> -)
> -) With the tiny amount of IPTV test content we enable, there's little
> -) awareness of it.  On a side note, a growing mobile population will 
> require
> -) wireless mcast support which I've current reservations about (ex. source
> -) control).   Although not for a lack in trying, mcast peering with 
> MaineREN
> -) participants is currently non-existent - they see it as desirable but 
> have
> -) had no time to devote to it.
> -)
> -) What's really missing is content.
> -)
> -)
> -)
> -) I believe R&Es contain a wealth of potential content ; content that 
> could be
> -) shared to wider audiences via mcast.
> -)
> -) We've started an (unfunded) grass roots effort to cast live consented 
> public
> -) events.
> -)
> -) The thought was to try and promote multicast within our R&E statenet as 
> well
> -) as to share such events to wider audiences among it and beyond.
> -)
> -) Our recent live events can be seen here 
> <http://www.networkmaine.net/iptv/>
> -) , with more on the way.
> -)
> -) I'd be happy to share further info/experience about the effort for any 
> that
> -) may be interested.
> -)
> -)
> -)
> -) I recently saw a message that I2 JointTech conference is contemplating 
> doing
> -) away with mcast sessions in lieu of unicast.
> -)
> -) I'd be interested in understanding it if someone on the list is aware,  
> as I
> -) would think that too bad should that occur.
> -)
> -) I wonder if that might be due to shallow interdomain mcast acceptance, or
> -) that R&E BW growth decreases the need for a more efficient (albeit more
> -) complex) transport, or perhaps to provide it within an interactive
> -) environment.  Losing any interdomain mcast content will further decrease
> -) usage.  Being personally interested in the content,  it's helpful to not
> -) only verify the mcast infrastructure but to use as example of how the
> -) service can be beneficial.   Believing that part of an R&E network's 
> role is
> -) to test/develop the network itself, it'd actually be nice to see it via 
> v6
> -) mcast.
> -)
> -)
> -)
> -) Appreciate any others' thoughts/insights.
> -)
> -)
> -)
> -)
> -)
> -)
> -)
> -) Description: Description: Description: cid:
> -)
> -)
> -)
> -)
>



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/