Skip to Content.
Sympa Menu

wg-multicast - RE: The state of interdomain multicast - ?

Subject: All things related to multicast

List archive

RE: The state of interdomain multicast - ?


Chronological Thread 
  • From: "Garry Peirce" <>
  • To: <>, <>, <>, "'Andrew Clark'" <>
  • Subject: RE: The state of interdomain multicast - ?
  • Date: Sun, 27 Feb 2011 16:23:30 -0500

Ge  wrote:

> wider adoption of multicast (IPv4 or IPv6) contingent on how much revenue can be generated

For further commodity/commercial adoption I agree, but I believe the transport efficiency is worthwhile itself between and within enabled R&Es.
> IPv6 presents options for SSM, but likely hood of AS removing multicast from bogons filters may be low

(assume you meant it’s typically found as a martian) We might assume that given a  level of desirable content, such an entry would not exist.

> intra-domain multicast will be around & prevalent; but for "inter-domain" like multicast, many large enterprises (eg., banking & financial sectors) get a direct feed to content providers/partners then do muliticast; for IPv4 inter-multicast routing that used the combo of MSDP/MBGP/MCAST, this is not a widely adopted model outside of I2

Agree – note that Interdomain v6 mcast should actually be significantly eased via embedded-RP.

At this time, this is also why I still see v4 mcast as value-add for participants to be part of an mcast capable R&E.

I’d put v6 in an adjacent value-add boat, although it’s being integrated faster as it has an impending train coming ;  when the next ‘Google’ is v6 reachable only.

Somewhat similarly, AMT seems for mcast what 6to4 is for IPv6 – a method to interconnect islands until native interdomain mcast is more prevalent.

 

From a video standpoint, interdomain mcast growth ultimately hinges having  desirable content.

On demand needs which cater to viewer’s schedules are better served by unicast.

So mcast seems to fit best in delivering live events.

 

I think the R&E community sits on untapped desirable content.  I like to envision R&E-TV as opposed to RealityTV.

Across our system, there are daily public live events bounded in their reach by geographic distance.

These lectures/media events are decent content candidates,  doing so for the common academic good.

I suppose a possible revenue stream might be to nationally aggregate R&E live events into an US UCAN Channel to be further produced and sold to a commercial broadcaster.

 

Could interdomain mcasting introduce a ‘game’ changing respect to collegiate sports currently handled by satellite?

Assuming a terrestrial paths exist, enabling interdomain mcast should be able to provide a lower BER/delay path along with multipoint delivery.

Would satellite then be seen as an expensive overlay, when a stable mcast infrastructure exists? 

(a RON might also rent a PTP fiber/wavelength given a path exists)

 

Curious - can anyone here provide a list of upstream mcast peers of I2?  How about a list of commercial providers providing global mcast service?

 

I think a World Mcast Day would be difficult given commercial v4 interdomain support (any one have a list of those that do?) , but perhaps an R&E World Mcast Day would be a more achievable goal in the

near term.

 

 

 

Description: Description: Description: cid:image001.jpg@01CBD447.3C4F5630

 

From: Ge Moua [mailto:]
Sent: Thursday, February 24, 2011 11:20 AM
To: ; Garry Peirce; ; Andrew Clark
Subject: Re: The state of interdomain multicast - ?

 

Me and 2 of my other colleagues just had an in-depth conversation about these issue you brought up.  There were many smart and devoted people who came up with with the working draft to make multicast possible; the multicast protocol suite when used for inter-domain routing does have its share of complexity but the overall mechanics of how multicast works is simple & elegant.

The conclusion that we came to:
+ wider adoption of multicast (IPv4 or IPv6) contingent on how much revenue can be generated
    * firms like netflix may have financial incentives to do unicast stream as they can potentially charge per stream
    * disconnect between financial incentives & technology efficiency (in the commercial world)
    * cache services like akamai / limelight fill niche that would make multicast more compelling
* IPv6 presents options for SSM, but likely hood of AS removing multicast from bogons filters may be low
* intra-domain multicast wll be around & prevalent; but for "inter-domain" like multicast, many large enterprises (eg., banking & financial sectors) get a direct feed to content providers/partners then do muliticast; for IPv4 inter-multicast routing that used the combo of MSDP/MBGP/MCAST, this is not a widely adopted model outside of I2

I too hope I2/Joint Techs do not remove the mcast working group or their sessions; this is one the few practical platforms where R&E folks can share some great ideas re: multicast.


--
Regards,
Ge Moua
 
Network Design Engineer
University of Minnesota | OIT - NTS
2218 University Ave SE
Minneapolis, MN 55414-3029
Email:  | Office: 612.626.2779
--


On 2/24/11 9:57 AM, 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 , 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: Description: Description: Description:
imap://moua0100@imap.umn.edu:993/fetch%3EUID%3E/INBOX%3E21927?header=quotebody&part=1.1.2&filename=image001.jpg

 




Archive powered by MHonArc 2.6.16.

Top of Page