All things related to multicast

["Marshall Eubanks" <>]

On Tue, 11 Oct 2005 10:17:42 -0400
 Alan Crosswell 
<>
 wrote:
> Show them the business model in which content providers finally are able 
> to afford providing content, which leads them to provide more content 
> rather than the current model of having to provide more copies of the 
> same content.  This results in more bandwidth overall as the number of 
> channels expands.
> 
> Did I get that right Marshall? ;-)
> /a
> 

Yes. 

It has  become apparent  to me that multicasting is becoming (or, at least, 
is likely to become) 
BCP for IP video distribution, but that there is a risk that this will be 
only a "walled garden"
distribution, closed both to the viewer and to outside broadcasters. This 
will do nothing for
consumer use of multicast and little for inter-domain deployment.

What's missing is (at least)

- a means  of mesh-based source discovery (i.e, something to replace sdr) 
that is standardized,
and that could be  used to plug into Electronic Program Guides. 

     (I am exploring doing this with  a combination of SIP and RSS / XML. 
Anyone interested should
get in touch.)

- a standard set of codecs (Brandon Butterworth  at the  BBC is working on  
this), and agreement on
the part of Video Service Providers have the ability to inject multicasts 
with these codecs into
their networks if their users want to join them

- some means of doing automatic rollover or tunneling (AMT) 

The I2 and related international networks are in a good position to ensure 
that the walled garden is
not the only means of video distribution. If internal agreement can be 
reached on the above issues
and implementations put into place with campus video service providers, there 
is a good chance the
market will follow.

Regards
Marshall

P.S. I  personally do not think that the walled garden will work in the long 
run, nor is it really
in VSP's best interest. If you apply likely Pareto distributions to the  
number of video channels,
you get order 100,000 profitable channels in the USA alone.  The  walled 
garden just won't scale to
those kind of numbers.






> McCallum, Robert wrote:
> > Decent list Alan.  I totally agree with the ISP being more multicast
> > centric.  I shall keep trying to hammer home the benefits to my companys
> > ISP faction and hopefully one day they actually might just listen :-).
> > 
> > -----Original Message-----
> > From: Alan Crosswell 
> > [mailto:]
> >  
> > Sent: 10 October 2005 21:54
> > To: wg-multicast
> > Subject: This coming year's multicast working group goals
> > 
> > 
> > Please comment on the following proposed goals for the Internet2
> > Multicast 
> > Working Group.  I would like to hear your opinions of things that you
> > think 
> > should be dropped from or added to the list, and whether you have any
> > interest 
> > in volunteering your time to help meet the goals.
> > 
> > Some of this work is done by volunteers.  Some is done by Abilene
> > engineering 
> > staff.  Some is done by Internet2 staff.
> > 
> > Mission
> > 
> > See http://multicast.internet2.edu/wg-multicast-charter.shtml for the
> > current 
> > mission statement.  I'm no good at mission statements.  Someone want to
> > take a 
> > crack at revising this or is it good enough?
> > 
> > Goals
> > 
> > 1. Encourage Source-Specific Multicast SSM
> >     - Why? Because MSDP won't scale and doesn't exist in IPv6.
> >     - How: Work with commercial I2 members, other vendors, and freeware
> >       producers to make their products SSM-capable.  This primarly means
> >       IGMPv3 support in
> >       a. end systems OSes (XP, Linux done.  MacOS X, other BSDs not
> > done)
> >       b. black boxes (e.g. Vbrick)
> >       c. client software (e.g. Real Player, Windows Media Player,
> >          StreamPlayerII, etc.)
> >          (Note that VLC already does SSM)
> >       d. switches
> > 
> > 2. Collect and disseminate multicast testing and debugging tools.  Much
> > of this
> >     has been done already but the tool list needs to be cleaned up and
> > extended.
> > 
> > 3. Continue to deliver training through Hands-on Workshops.
> > 
> > 4. IPv6 Multicast
> >     a. Work with v6 working group to bridge v6 and multicast workshop
> > content.
> >     b. Encourage use of embedded RP in Abilene and other R&E networks.
> >     c. Make sure the toolset for v4 also works for v6.
> >     d. Work with switch vendors to encourage/evaluate MLDv2 support.
> > 
> > 5. Liaison with related working groups
> >     a. IETF MAGMA
> >     b. Internet2 bigvideo, v6, measurement, routing, etc.
> >     c. Security group(s)
> >     d. International R&E groups
> > 
> > 6. Push commodity ISP adoption of multicast routing
> >     a. Talk to the ISPs and try to convince them of the value.
> >     b. Work through the Quilt and gigapops to make multicast routing a
> >        requirement for ISP contracts.  Highlight those ISPs that already
> >        offer multicast peering.
> >     c. Talk to home access provider ISPs to try and encourage multicast
> > support
> >        so our residential broadband users see the same benefit as our
> > on-campus
> >        users.
> > 
> > 7. Clean up the http://multicast.internet2.edu web site.
> > 
> > 8. Invent the multicast killer app:-)
> > 
> > 
> > Thanks.
> > /a
> >