All things related to multicast

[(Kevin C. Almeroth)]

This is my summary of some of the items we discussed at the multicast
working group meeting at the FoD workshop in Santa Barbara.

One-sentence summary:  ``It's about deployment now...''

Deployment has become the big key.  Deployment in the backbone is fine 
and running smoothly.  Deployment in the gigapops and member institutions
needs help.  It needs the killer app, it needs awareness, it needs
incentives.  Much of the discussion at the meeting involved how to
motivate deployment.  Oh, but there was one other topic too.  I'll
do it first:

Topology
--------

   The big issue here is effort to install an Internet2 router that
peers with the commodity Internet multicast community via the MIX.
This router should be in place relatively soon.  One issue that has
been on the table for some time is how to deal with the potential
differences in traffic rates between I2 and the commodity Internet.
The answer:

   * Create an admin-scoped space for Internet2-only apps.

   * Develop a mechanism to limit the amount of I2 multicast traffic
     that is allowed to flow through the MIX.  (This is my way of
     summarizing the goal.)  This generated some pretty hefty debate.  
     The issue, is why and how?  The bottom line is that we can attack 
     this problem in three ways:

        1. Develop some QoS mechanisms to do provisioning (applicable
           to not only multicast but unicast traffic as well).

        2. Develop application layer guidelines for folks who provide
           multicast streams, i.e. use layering for traffic available
           to the commodity Internet, etc.

        3. Enforce a per-group or aggregate rate limit for multicast.
          
Only #1 provides a non-hack solution to too much traffic.  #3 works
but this also begs the question of what "too much traffic" is.  The
outcome of the meeting was to talk to the MIX folks and see what
should be done.  In the end, this really becomes part of the peering
arrangement between the I2 NOC and the MIX.

Disclaimer:  I tried to be impartial but don't know how well I succeeded.

Final note:  This discussion does not address the
issue of heterogeneity that we discussed in Miami (see Ken Lindahl's
slides on the WWW page).  This problem really ought to be solved
using #2.  The proposal to imbed flow rate information in the multicast
address (different group ranges for different rates) is problematic
because it violates layering abstractions and it is difficult to
implement as more than a recommendation.

------------------------------------

Motivating Deployment
---------------------

This was again a hot topic.  Let me add my two cents first and say that
multicast deployment has been painfully slow around the entire world,
not just in Internet2.  The problem is that there is not a single reason
for slow deployment but rather a set of reasons that span different 
communities... from no killer app to not enough tools to too many tools
to not enough bandwidth to whatever, whatever.  Regardless of what the
reason de jur is, we tried to put together a set of directions the working
group can go in to help motivate deployment.

   1.  Continue to have an "intro to multicast" workshop at the
       beginning of the Joint Techs meetings.  Continue to have
       a "troubleshooting" meeting at the end.  We did this in
       Miami with some success and will do it again in Minneapolis.

   2.  Develop a matrix of member institutions and list whether each
       institution has deployed multicast.  We could have several
       levels if desirable:  partial deployment, full deployment,
       stable receive capability, stable send capability.

       A sub-point here is that my group at UCSB (and numerous other
       folks elsewhere) are working on measurement tools.  While this data 
       is too low-level to impress most folks (CIOs), I think we can produce 
       some good high-level data that talks about traffic amounts, etc.

   3.  There was a proposal to have a multicast apps workshop.  But,
       discussion suggested there was not yet enough interest to do
       this.  Instead we will have a slot in the main program at the
       Spring Member meeting.  Russ Hobby is helping to develop the
       message (and already doing a darn fine job!!).  Unfortunately, 
       this is bad timing and conflicts with the IETF and Infocom.
       We will see what we can put together.

       A sub-point here is that we also need to start tracking applications.
       If we did have a workshop I wanted the creation of an application
       tracking mechanism to be an outcome.  In any event, I'm looking for
       someone to take the task and run with it...  this will involve doing
       lots of leg work, creating a WWW-based report with hyper-links, etc.

   4.  Find more content.  The UO/Cisco folks are pushing hard to come up
       with follow-on events to NetAid.  We need to do more publicity and
       find additional non-geek content.  I think over time, this will become
       easier.  Ted Hanss and I have been talking to the Shoah Foundation,
       a Spielberg-sponsored Holocaust Foundation with lots of content.  Also,
       the Santa Barbara Film Festival was just in town.  Also, there are
       lots of Film Studies students in the world doing there thing.  I
       think a lot of this content may be worthwhile to put on a channel.
       We should also follow-up on other content (non-video) distribution
       mechanisms.  

------------------------------------

Long, rambling, and chock full of errors.  But at least you have the details.

-Kevin